Up and Running with Git Transcripts
Chapter: Teamwork: Branches
Lecture: Reason #1 for branching: Bug fixes

Login or purchase this course to watch this video and the rest of the course contents.
0:00 There are different reasons. You might want to create a branch and start working over
0:04 there instead of writing your main branch or wherever you happen to be working at the
0:09 moment, understanding the different reasons and the different use cases will be really strong indicators
0:15 for you to know when you should branch and how to do that?
0:19 Obviously the command is the same,
0:21 but the techniques applied and when stuff is merged or how you think about the other
0:26 stuff happening at the same time really varies depending on what you're trying to do.
0:30 So let's have a look the first reason we might care about our bug fixes.
0:36 So we've got different releases of our application.
0:39 Now, if you have a web app,
0:41 this probably doesn't make sense. There's only one version of the web app unless you
0:45 deliver some kind of on prem solution for a SASS business or something unusual like that
0:50 But anything that's like a library you're delivering to other people,
0:55 a python package or a desktop application or any of those kinds of things,
1:00 then definitely you could be in this scenario,
1:03 you released versions over time, different people are using them.
1:07 Maybe there's a breaking change from version 1 to version two.
1:11 You can't necessarily bring all the stuff back from two that has maybe a bug fixing
1:17 it to help the people on one because or 11 because they can't change right there
1:22 not necessarily ready to change or they might not even own a license to this.
1:26 Right. If you're selling different versions and they've got to pay to upgrade.
1:29 So what happens if you've already released version 1, 1.1 and two and you're still like you're
1:35 working on to one and beyond your past this,
1:38 right? Somebody comes and says there's a problem with 1.1
1:41 we need to fix it.
1:42 How are you going to do that branching?
1:45 That's what you're gonna do. So what you'll do is you're going to create a
1:48 branch over here and you're going to make those changes And maybe you'll call this now
1:54 113, you can apply tags at these different levels to help you find them.
1:59 So you might say this part,
2:00 this new branch, we went over here and now here is what we consider to
2:03 be the release 113 and that's what we're shipping to customers.
2:08 So by doing this, we have not affected version two,
2:12 we've also not affected version one and whatever happens to be the current development for the
2:16 next version of two plus That's not affected by this.
2:20 So what we can do is we can use these branches to spin off some parallel
2:23 development effectively time travel back to what we released for 11 and say in this world
2:30 where we're at 11, we want to continue down a different path where we fix
2:34 that bug and ship that to customers ideally don't ship bugs,
2:38 but you know, it happens to hear this bug fixes story,
2:42 this is a really common way of branching and not necessarily bringing it back?
2:48 So you gotta decide to the changes you made in the past.
2:51 Do they still apply to the future if they did well then you probably want to
2:55 merge those bug fixes forward? But let's imagine in 11 we were on one UI
3:01 framework and we switched over and two and the bug was in the old UI framework
3:04 so there's just no reason to bring that forward,
3:07 it might just stop here unless for some reason we need to patch 113.
3:12 Alright, so reason number one bug fixes.