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 story. They look a little bit similar.
0:10
Again, we have our main branch but it's a little more focused and controlled, you know that you're committing to do this feature,
0:18
you know that maybe even it's just a bug fix, but you want to have a very clear line of development and path that you can
0:27
trace back to say here are all the changes, not just one giant commit, but here are a bunch of changes in conversations around
0:36
adding this feature. Here is a set of conversations around some bug fix. And because these are separate branches,
0:43
we're going to be able to actually have one person working on the bug fix,
0:47
one person or team on some feature and they're not going to interfere with each other
0:51
So we're gonna come over here and say we want to add a new feature do a bunch of work on that feature over time,
0:59
these colors here are meant to indicate that some of the time the app, the feature is not ready to be brought in. If you try to bring it in,
1:06
it's going to destabilize the development right? Like at that red bar part, if we were to commit those changes back to the main line,
1:14
maybe we're doing that async thing, but it's only halfway done. It's not really complete.
1:21
And so the app might not even run or if it's a compiled language it might
1:25
not even compile, you definitely don't want to be putting that back in the main
1:29
branch, but eventually you get to this little green bar where everything is good, this feature is done and you're ready to bring it back.
1:36
So then you merge it back into the main branch, you can have code reviews and all sorts of stuff around that before you like,
1:43
Alright, here are all the changes, yellow, red, yellow, green, let's talk about them, polish them, and when we're ready, then all in one shot,
1:51
we're going to bring those back into the mainline. And what's cool about that is you can actually go and trace that back over time
1:58
you can see a little bit more detail about the people that worked on it and so on. Often this is structured at what's called a pull request,
2:06
talk more about that in a little bit. But this idea of breaking off to work on a feature and then when it's completely
2:12
ready, bringing it back, that's a little bit like stable development,
2:16
but it's way more polished because instead of just pushing these changes back and everyone's working
2:22
on the Purple Dev branch, every feature or every bug fix has its own branch where all of its work happens and then it's brought back when it's ready.
2:31
Different from experimentation, because you're definitely planning on adding this feature, you're definitely planning on doing this bug fix,
2:37
so you're not putting out their speculatively, you're actively creating this branch so that you can say, here's a stable isolated place for us to work,
2:45
let's do that. And then when we're finished, we'll bring it back over so we don't interfere with other people or just the stability of the project.