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