0:00 Hey everyone, welcome to my last little vision thing at GitHub. Today we are going to talk about guest branches, which is a concept that's been bouncing around for a few years now and which I think has a lot of potential. 0:16 So this video is basically my way of saying, hey, please, please make this thing. So let's go into what this thing is. We can cover a bit of history. 0:26 So on the first day, GitHub made forking as a mechanism to diverge projects, right? To take one project and take it in a different direction. And it was good. 0:38 On the second day, GitHub made the pull request to submit changes back to the original repo. And it was, you know, it was okay. It was fine at the time. 0:49 And then on the third day, the entire rest of the industry copied this model to a T and now we're all stuck with it. 0:56 So I think forks are great for diverging projects, for taking a project like React or Rails and saying, all right, you know, my company needs a version of this, but not exactly what the original repo has. 1:08 Or I actually believe in a totally different direction for the project. But forking isn't really that great for one off contributions, right? 1:19 So with where open sources today, where people are contributing on a fairly regular basis to open source repos, it's not nearly as good a solution. 1:28 So the extra overhead that comes with forks, right? Having to actually create a fork and sink and we'll go over what these, you know, what these actual frustrations and overhead look like. 1:39 But they make them very frustrating and inefficient as long term vehicles for contribution. 1:46 So if I'm contributing to React over a period of five years, right, I have to do all of these actions that make it really kind of a pain, especially when compared to contributing code to repos where I do have write access, which is just like a branch in the PR. 2:02 So enter guest branches, which is basically a model where forks are exclusively for diverging code bases. 2:11 And then guest branches or branches in general are for contributing code to a repo, whether you have write access or not. 2:19 So it tries to consolidate and streamline the mental model a little bit. 2:23 So here's what contributing to open source feels like today with the forking model. 2:29 Let's say I'm a junior engineer. I want to fix a bug that I found in React. 2:35 And this let's say this is my first open source contribution. 2:39 So I'm excited. I open like I look around here. It's like, oh, cool. 2:44 You know, whatever. Anyway, I clone it and I make my changes. 2:49 And so far so good, right? This is me working after cloning. 2:53 And all right, I'm done. I fixed the bug. I commit my changes to a branch and then I push it to the repo so I can open a PR just as I always do in my other projects and in my work. 3:05 But then I get this message. So since I don't have write access, I'm blocked. 3:11 And the message itself isn't especially clear to a beginner. Right. I've never had to make a fork. 3:17 So I don't you know, I don't know what not having write access means necessarily. 3:22 I don't know how to get access to the repo. 3:25 And I'm not sure at this point how people even commit to open source then. 3:29 So basically, there's a lot of Googling I would need to do in order to build an understanding around the forking model. 3:36 So let me just, you know, open up the file in the UI. 3:41 Right. Easier. I'm just going to click the edit button. Simple enough. 3:45 And my change is easy. So this makes sense. 3:48 So I open this up and immediately I see this message. 3:52 You're making changes in a project you don't have write access to. 3:55 We've created a fork for this project for you to commit your proposed changes to. 4:00 Submitting a change will write it to a new branch in your fork so you can send a pull request. 4:05 Right. It doesn't really explain what a fork is. 4:09 And this is just another concept to add to my grown list of things I don't fully understand. 4:14 Right. I've already had to learn Git. I understand how to work kind of with a team of people through PRs. 4:20 But now there's also this concept of the fork, which I, you know, I don't 100% understand because I'm just trying to change the original repo. 4:28 So anyway, I scroll down to make my change. I make the change. I go down to proposed changes. And I click propose. 4:36 And this takes me to the compare page as, you know, this thing always does. 4:42 Which by the way, we should probably just skip this page when you're making changes via the web UI. 4:47 They're like simple changes. You know what they are. This is just a pretty redundant step. 4:51 But anyway, let's click create pull request. So now I have this concept of a fork. Right. 5:00 I don't know exactly what it is yet. Maybe. Or maybe I've Googled it. 5:03 And also what I'm seeing here is I understand now there's a base repo and a base branch versus a head repo and a compare branch. 5:12 And I've also got this check box down here that says allow edits by maintainers. Right. 5:18 So all I wanted was to make one like a one line change to fix a bug. 5:23 And I have to learn all of these new concepts to do that and keep them in mind in the future as I want to make other simple changes. 5:31 So let's add a description and create this PR. Click allow edits by maintainers. I think that makes sense. 5:39 And all right. It is done. Right. We have our PR. Our PR is on the Facebook repo. 5:50 Whereas I have a different repo, which is where I've actually made the changes. 5:56 So like what is this fork thing? Right. Where do I learn that this is how I'm supposed to make changes moving forward? 6:04 So let's say I'm lucky and someone explains it to me and I'm like, OK, this is how I commit to open source. 6:11 Now I want to make more changes and I'm going to use my fork to do that. 6:14 So I, you know, come and clone the repo again. This is kind of weird to clone a repo that isn't the actual repo I want to update. 6:23 Right. This feels like inherently kind of redundant and indirect where this this entire object exists only as a mechanism for me to change the original object, which is what I actually want to do. 6:37 So I'm going to clone it. Well, you know, this is just a bummer. This is a bit of an edge case, but it's it is a frustrating experience because I've already cloned the original one. 6:49 So let's remove that and then clone the fork. I've done that. And then I am going to check out my branch. Right. Same branch. Make some changes. Run them. Update my branch. 7:00 It's not the smoothest process, but OK, you know, we're done. And, you know, I can submit that PR and everything's great. Right. And I go back to my work and I'm I'm a happy camper. 7:13 But now sometime later, I've run into another improvement that I can make to react. Right. I am. I'm a very, you know, a very good part of the community and I want to contribute again. 7:26 And the repo has changed a lot in the interim. Right. Maybe there's a new version out. Maybe there's just a whole bunch of changes. Right. These are very high volume projects. 7:35 And so at this point, my clone is seriously outdated and my fork is too. So when I try to make changes, I always run into these scary merge conflicts. 7:45 And so what I'm doing now is I'm going to Google how to update my clone and I'm going to do that. Now, this brings up, you know, several new terms. Right. 7:55 I need to add a new remote. Right. I've never had to configure a remote. Origin has always been enough for me. 8:02 So now I need to know what a remote is. And then I need to start learning these concepts of upstream and downstream and what those mean. 8:10 And then I need to fetch the upstream. Right. From one repo to merge it into the main branch in mine, which is downstream. 8:20 And all of this is happening in the same folder. Right. I can also do this on the Web. That's also going to lead to some weird merge conflict UI. 8:28 But all right, I'll do this. I'll set the thing. And I'm going to do it fairly frequently. Right. If I intend to contribute a lot. 8:38 This is something I'm going to have to do every time before I contribute versus, you know, working on your own repo where you just branch off of your main branch. Right. 8:50 Sometimes I mean, there's there's engineers who do this many times a day for a lot of different repos. 8:57 And it's become a contributors job to keep their fork in sync with the original repo, which takes time. Right. 9:03 It takes the time it takes to download. It takes like thinking about it constantly running migrations if you need to. 9:10 So if a fork exists only for contribution and not as a standalone project, this is all just useless overhead. 9:18 This is all work to, you know, sustain the current model of how things are done. Right. 9:25 There's no necessary need for all of this stuff. So what happens and what I've heard from a lot of people, actually, is many engineers simply delete their forks after they're done and then create new forks whenever they want to contribute. 9:38 So they go through this entire process every time. And that's easier and faster than, you know, keeping their older fork in sync. 9:45 And if that isn't a signal that something isn't working, I really don't know what is. 9:50 So let's talk about guest branches. Right. I think this concept can really alleviate a lot of this overhead and really kind of turn open source on its head and make it way, way more natural and maybe even funner to contribute to open source. 10:06 So here's how it could feel. So I'm that same junior developer. Right. I open an open source repo for the first time. 10:14 I've never contributed to a repo that I don't have write access to. So this is my first time doing that. 10:20 And let me go just edit with the Web UI at this point because it's a simple change. 10:25 There's no message at the top. Right. Explaining what forks are, because I actually don't really need to know what forks are. 10:31 It's just a regular contribution. So I go down, make my change. 10:36 And then I'm going to propose the changes again, just as I would regularly do. 10:41 And here I'm introduced to a new concept, a guest branch. 10:46 It says since you don't have write access to this repository, this branch won't appear in the branch list and won't be included in a Git clone for other people unless they fetch it manually. 10:57 So pretty simple. I mean, it is a bit to wrap your head around, but it's still acts and functions like a branch pretty much entirely. 11:07 So in the past, we discussed having like a custom clone for each person on their account. 11:15 So like I would say, you know, Git clone, whatever, or Git pull. 11:19 And it would pull all of the branches that are relevant to me, like guest branches. 11:24 And that would skip this manual step of fetching that I'll talk about in a second. 11:28 But what that would require would be a complete overhaul of our Git server, which would take like at least six months and might affect performance for everyone. 11:39 And it's a lot for a feature like this. So manual fetching for now felt like, you know, pretty good balance. 11:45 You'll notice I also don't need to worry about allowing edits by maintainers. 11:49 There's like that checkbox is gone because of course they can edit. 11:54 Like I'm contributing to their project. That's what I'm trying to do. 11:57 So I'm going to create the pull request. My PR shows that this is a guest branch. 12:02 It has instructions here on the on the right sidebar for how to get it locally, which is just, you know, Git fetch. 12:09 You can copy that. You can paste it. You can like click the clipboard icon and get like the fetch command as well. 12:16 We could also do the extra step and literally give you the command to fetch and then check it out and make it especially easy. 12:24 But now this PR is the same as any other PR on the repo, except for this guest branch designation. 12:33 The other difference is that CI can require a maintainer authorization potentially before running. 12:40 This is to avoid sapping resources like you don't know how many randos are going to be opening PRs. 12:47 We could let admins toggle the setting, but I thought it would be cool to have like an additional gate there for maintainers to be able to control this. 12:58 And then one new new thing you may have noticed is the author's module in the sidebar. 13:04 This isn't something tied specifically to to guest branches. It's just something I've wanted to see for a long time. 13:11 So assignee never really meant anything on PRs. It means something on issues. It's like who is tackling the issue. 13:19 But on PRs, the author, the creator is usually the person who's working on it. 13:24 And there may be multiple people. Right. So it's less about who do I assign this PR to and it's more about who's currently working on this PR. 13:31 So assignees is generally a waste of space. Authors is a thing that I think can be really valuable in replacing it. 13:40 So the way I see this is it would include every person who contributed or co-authored any commits on the branch, as well as any person manually added as a contributor. 13:52 So this not only gives you kind of an at a glance understanding of who is involved in a PR, it also gives us an important structure or role potentially to base permissions off of. 14:06 For instance, like who can accept the suggested change? Who do we surface certain like author only features to, especially for, you know, PRs that have people pairing on them or something? 14:19 And then guest branches don't appear by default on the branch list or the branch count. 14:28 So they really there are kind of pseudo branches and they don't add noise to the to the upstream repo, which I think is very important for something like this. 14:39 Right. Because forks take all the work and they kind of outsource it, basically, and put it somewhere else. 14:46 So you're not kind of facing it all the time and we can do the same thing here. 14:49 So by default, I only see the branches that are created on the repo itself by maintainers with Write access. 14:56 I can click onto the your branches tab and see which branches I have, you know, in effect or, you know, just get easily get to my work. 15:05 And I can also search for fixed branch and find other people's guest branches. 15:11 This is like we can figure out permissions and see if we even want this to be possible. 15:17 But you can see that all of the branches here follow a specific syntax. 15:22 So it says guest slash username slash whatever the branch name is. 15:27 And we can choose anything for this, make it easier and make it, you know, a bit more complex, whatever you want. 15:32 But it's a native part of the repo rather than being this like artificial external thing. 15:39 I don't have to look at a totally separate repo to see the change. 15:44 And you can notice like right now in the top right, React has over 30,000 forks, right? 15:52 A lot of forks. 15:53 And maybe like what, 50 of those, 100 of those are actually diverged projects, like projects that are never, you know, intended to be, sorry, never intended to be, you know, a part of React, right? 16:08 They have diverged, they might still be pulling changes, they might still be pushing back changes, right? 16:14 So cross fork PR still makes sense. 16:17 But everything else, right? 16:20 Everything else is really just one off branches in this model. 16:24 And the majority of that is stale, right? 16:28 People have these forks that they just forget about. 16:33 So you can imagine in this model, you would have 100 forks. 16:37 And when someone clicks on forks, they will see different versions of this project, not one off forks that are created for contribution. 16:46 So let's try updating this repo locally like we did before. 16:51 So I clone the repo, I do some work and I push, right? 16:54 Same as I did before, no, you know, no forking, no changing the remote. 16:58 And now my push got blocked still. 17:01 But this time it's because my branch name didn't match the correct syntax. 17:06 So the message is pretty simple. 17:08 And I have a straightforward way to correct this. 17:11 In fact, I'm even given the command to run to rename this branch. 17:15 So I do that. 17:17 And then I push back to the origin. 17:20 And it's pushed, it's done. 17:22 And I get a note that, you know, this is a guest branch and must be manually fetched by others. 17:28 Right? 17:29 So the only difference to me between the flow to kind of create this and the flow to create any other branch, any other PR or contribution on repos that I own is literally just the branch name. 17:42 And knowing that other people need to fetch it manually. 17:45 That's it. 17:47 And even easier, right, I can edit the file in the new GitHub.dev editor. 17:52 Right? 17:53 I can just click onto this, not create a fork, not create anything, see the entire repo. 17:58 Right? 17:59 I don't have to, like, fork it or anything. 18:00 Right? 18:01 I can just create a guest branch, like that easily straight on the main repo. 18:06 This could push me to the, like, creation, PR creation flow. 18:10 So these branches don't add noise because they're technically not part of the repo. 18:15 Right? 18:16 You don't receive them when you clone a repo unless you fetch them manually. 18:19 Like, you actually have explicitly said you want them. 18:22 And they don't appear in any of the lists. 18:24 In terms of implementation, right, they could easily be invisible forks that are presented as just, like, upstream branches. 18:32 Right? 18:33 We can figure out how to actually build this. 18:36 But the mental model itself becomes way, way easier. 18:40 So this is the process in today's fork world. 18:44 The new concepts you have to learn along the way are in red. 18:48 So a first-time contribution is easy enough. 18:50 You open a repo. 18:51 You set up a fork. 18:53 You clone the fork locally. 18:55 You push to the fork. 18:56 And then you open a PR from the fork to the upstream repo. 18:59 And click allow edit by maintainers. 19:02 Alright? 19:03 Like, not the funnest or smoothest flow, but pretty clear. 19:08 Now, repeat contributions get really annoying. 19:11 You have to configure an upstream repo. 19:16 And you have to keep your repos in sync regularly. 19:19 So, again, like I said, many contributors just skip these steps and, you know, delete and recreate their forks because this is just so annoying. 19:31 And then maintainer reviews, which we haven't really talked about, also suck, right? 19:34 So to review a contributor's PR, and to get that locally and to run it, they have to configure a one-off remote pointing at the contributors fork, fetch the changes, switch branch for testing. 19:46 And, like, that's for a one-off if it's a one-off contributor. 19:48 So as they go through this, they have to learn forks. 19:51 They have to learn about this idea of separate repos for the same thing. 19:55 They have to, like, keep those separate repos in sync, learn about upstream and downstream, learn about configuring remotes. 20:01 Like, it's a lot. 20:03 It's not, like, it's not super complex. 20:05 It's totally manageable, but it could be better. 20:08 So with guest branches, like, all of this is simplified. 20:12 I'm going to jump back. 20:13 Like, this is a lot. 20:14 This is, you know, kind of what you would expect from a tool to do the specific task, right? 20:21 So here, the first-time contribution, right? 20:23 It's easy to contribute and review all of these things. 20:26 It's as easy as doing it on your own branch. 20:28 You open a repo, you clone it, you push to the repo, this time with a specific branch name, and then you open a PR the way you would. 20:35 And repeat contributions are the same as the first forever. 20:39 You don't need to pull from an upstream. 20:41 You just need to pull from the repo that you have and just go to, like, main and branch off of that. 20:47 And then maintainer reviews are also way easier. 20:51 They already have the repo. 20:52 All they need to do is fetch your branch and then switch over to it. 20:55 They don't need to configure any remotes or anything like that. 20:58 And all you really have to learn is this idea of, like, oh, there's some branches that are slightly different in some way. 21:04 And fetching, which, you know, you probably need to learn anyway. 21:09 When we introduce the feature, we can prompt contributors to delete their forks and see that 30,000 number just, you know, drop. 21:17 Because, again, like I said, most of these forks are stale and unused. 21:22 And let people delete. 21:24 Or we could even encourage them to try and tackle a good first issue as, like, a way of testing out guest branches. 21:31 We can also optimize the CI runs, right? 21:35 So we don't need a maintainer to always authorize them by creating this new trusted contributor role. 21:41 So you can see, you know, right where my face is, unfortunately. 21:45 This thing of just, like, hey, this is the third contribution for this person. 21:50 Do you want to set them as a trusted contributor and automatically run their checks? 21:53 So just a little optimization there. 21:55 And then another cool thing is we can use this exact same model and tech, however we build this, to build a concept called hidden branches, which we talked about in the past, which can be used for sensitive security issues that maintainers want to keep under wraps. 22:11 So kind of exactly the same thing. 22:15 In terms of, like, what we call this thing, right, I've been calling it guest branches because that's the term that stuck for me. 22:22 But this could just as easily be lightweight branches or pseudo branches. 22:25 I personally, I like guest branches. 22:28 And we can also package it and frame it in a whole lot of different ways to encourage different behaviors. 22:34 So we could think about it as a friendly visitor to the repo, right? 22:38 I'm just here to help out. 22:39 Like, it's a fun thing. 22:41 It's like, here's me saying hello, friendly neighbor. 22:44 And this could remind maintainers that contributors are really just trying to help and make this a generally, like, pretty positive thing. 22:51 We could think about it as a star for the contributor, right? 22:57 Encouraging contributions via recognition, like good students. 23:01 So here's a star for doing good. 23:04 Or we can be more technical, right? 23:06 We can show that these, you know, aren't quote unquote real branches, right? 23:11 But really they're like, I'm here just visiting very quickly type branches. 23:15 Or even, you know, actually surface the model, which is they are technically external. 23:22 And show, hey, this is not really part of this repo. 23:26 Which could also be good for security, right? 23:28 For people reviewing or looking at a specific branch to know that they should treat that as someone external. 23:37 Or we show these branches of temporary. 23:39 So there's like a lot of ways to think about it. 23:41 There's a lot of ways to package it. 23:43 And I think we can really shape how people feel about contributing to open source. 23:50 And, you know, build a culture around it. 23:52 Not that there isn't already one. 23:53 But how we treat guest branches, how we think about the main way people contribute to open source. 23:59 Can I think change the way that people feel about it themselves. 24:02 So anyway, I think guest branches could make contributing to open source substantially more efficient and enjoyable. 24:12 And I think it would likely result in a noticeable growth in open source contributions on GitHub. 24:17 Especially from new developers who just have never learned this, you know, complicated forking method. 24:25 Bottom line is I think we should invest in this and make the industry better as a result. 24:31 And that's it. 24:33 This is Joel signing off. 24:36 Last time you see my bed in the background. 24:39 It was an absolute pleasure to work with all of you. 24:44 And I'm really excited to see what you do next. 24:47 And yeah, please make this. 24:50 Alright, bye.