Up and Running with Git Transcripts
Chapter: Teamwork: Branches
Lecture: Reason #4 for branching: Feature branches

Login or purchase this course to watch this video and the rest of the course contents.
0:00 Reason for branching # four are feature branches feature branches are somewhat like this experimentation
0:07 story. They look a little bit similar.
0:09 Again, we have our main branch but it's a little more focused and controlled,
0:14 you know that you're committing to do this feature,
0:17 you know that maybe even it's just a bug fix,
0:21 but you want to have a very clear line of development and path that you can
0:26 trace back to say here are all the changes,
0:28 not just one giant commit, but here are a bunch of changes in conversations around
0:35 adding this feature. Here is a set of conversations around some bug fix.
0:40 And because these are separate branches,
0:42 we're going to be able to actually have one person working on the bug fix,
0:46 one person or team on some feature and they're not going to interfere with each other
0:50 So we're gonna come over here and say we want to add a new feature
0:53 do a bunch of work on that feature over time,
0:58 these colors here are meant to indicate that some of the time the app,
1:02 the feature is not ready to be brought in.
1:04 If you try to bring it in,
1:05 it's going to destabilize the development right?
1:08 Like at that red bar part,
1:10 if we were to commit those changes back to the main line,
1:13 maybe we're doing that async thing,
1:16 but it's only halfway done. It's not really complete.
1:20 And so the app might not even run or if it's a compiled language it might
1:24 not even compile, you definitely don't want to be putting that back in the main
1:28 branch, but eventually you get to this little green bar where everything is good,
1:32 this feature is done and you're ready to bring it back.
1:35 So then you merge it back into the main branch,
1:39 you can have code reviews and all sorts of stuff around that before you like,
1:42 Alright, here are all the changes,
1:44 yellow, red, yellow, green,
1:46 let's talk about them, polish them,
1:47 and when we're ready, then all in one shot,
1:50 we're going to bring those back into the mainline.
1:53 And what's cool about that is you can actually go and trace that back over time
1:57 you can see a little bit more detail about the people that worked on it
2:01 and so on. Often this is structured at what's called a pull request,
2:05 talk more about that in a little bit.
2:07 But this idea of breaking off to work on a feature and then when it's completely
2:11 ready, bringing it back, that's a little bit like stable development,
2:15 but it's way more polished because instead of just pushing these changes back and everyone's working
2:21 on the Purple Dev branch, every feature or every bug fix has its own branch
2:26 where all of its work happens and then it's brought back when it's ready.
2:30 Different from experimentation, because you're definitely planning on adding this feature,
2:33 you're definitely planning on doing this bug fix,
2:36 so you're not putting out their speculatively,
2:39 you're actively creating this branch so that you can say,
2:41 here's a stable isolated place for us to work,
2:44 let's do that. And then when we're finished,
2:46 we'll bring it back over so we don't interfere with other people or just the stability of the project.