Up and Running with Git Transcripts
Chapter: Course conclusion
Lecture: Reasons for branching

Login or purchase this course to watch this video and the rest of the course contents.
0:00 We spent a long time talking about the reasons for branching,
0:03 not just the mechanics of it,
0:05 because what you're trying to accomplish with branching determines how you want to do it in
0:11 your expectations and how you arrange it.
0:13 Said one good reason for branching is a bug fix.
0:16 We've already gone on and created a release for 1112 and we're working on 2.0
0:22 2.1 or 2.3 or something like that.
0:24 We get a bug report for version 1.1
0:26 of our app or our library.
0:27 We can use branching to spawn off a parallel branch from back in time.
0:33 Do the fix and release that for people on the older version,
0:38 you can get more stable development if you're not checking directly into the main branch,
0:43 but instead committing somewhere else. And then once you've got a stable feature,
0:49 merging that back over, here's a simplistic way of doing that,
0:52 you might just have everybody work on the dev branch and then periodically,
0:56 when you get a feature that ready,
0:58 you merge that over this might work fine for very small teams.
1:02 I'm not sure I would recommend it,
1:03 but sometimes sometimes it's totally good.
1:07 More often you'll want to create feature branches or other branches for say,
1:12 experimentation. So here we could say,
1:14 I'd like to consider rearranging our Ui and it's an angular and we're going to switch
1:20 to view. Would that be a good idea?
1:22 If I just start making those changes and wrecking the Ui.
1:25 Well, nobody else will be able to use the App build it and develop it
1:30 so we can create a branch,
1:31 explore that idea. And if it doesn't work out we just don't commit it.
1:34 Same thing for async orm's.
1:36 This one did work out, so we merged it back in.
1:40 We can be more specific and more thoughtful about this with the idea of feature branches
1:44 instead of are just stable development,
1:46 every feature or every bug fix can have its own branch that exists for basically the
1:52 duration of that feature development lifetime.
1:55 Once the feature is done, we merge it back in,
1:58 we can do that through just a straight merge or we could do a pull request
2:02 straight to ourself. Remember? The pull quest gives us more structure,
2:07 especially on, github to have a conversation about it,
2:09 we have code review, we have continuous integration,
2:12 we have people who are assigned to it,
2:13 we have a conversation around it that's more support and more visibility than just I worked
2:20 on some branch for then I did merge and I wonder why that happened.
2:24 Probably I would recommend doing the pr style workflow for this one, but you all can figure it out what works best for you.