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, not just the mechanics of it,
0:06 because what you're trying to accomplish with branching determines how you want to do it in your expectations and how you arrange it.
0:14 Said one good reason for branching is a bug fix. We've already gone on and created a release for 1112 and we're working on 2.0
0:23 2.1 or 2.3 or something like that. We get a bug report for version 1.1 of our app or our library.
0:28 We can use branching to spawn off a parallel branch from back in time. Do the fix and release that for people on the older version,
0:39 you can get more stable development if you're not checking directly into the main branch,
0:44 but instead committing somewhere else. And then once you've got a stable feature, merging that back over, here's a simplistic way of doing that,
0:53 you might just have everybody work on the dev branch and then periodically, when you get a feature that ready,
0:59 you merge that over this might work fine for very small teams. I'm not sure I would recommend it, but sometimes sometimes it's totally good.
1:08 More often you'll want to create feature branches or other branches for say, experimentation. So here we could say,
1:15 I'd like to consider rearranging our Ui and it's an angular and we're going to switch to view. Would that be a good idea?
1:23 If I just start making those changes and wrecking the Ui. Well, nobody else will be able to use the App build it and develop it
1:31 so we can create a branch, explore that idea. And if it doesn't work out we just don't commit it. Same thing for async orm's.
1:37 This one did work out, so we merged it back in. We can be more specific and more thoughtful about this with the idea of feature branches
1:45 instead of are just stable development, every feature or every bug fix can have its own branch that exists for basically the
1:53 duration of that feature development lifetime. Once the feature is done, we merge it back in,
1:59 we can do that through just a straight merge or we could do a pull request straight to ourself. Remember? The pull quest gives us more structure,
2:08 especially on, github to have a conversation about it, we have code review, we have continuous integration, we have people who are assigned to it,
2:14 we have a conversation around it that's more support and more visibility than just I worked
2:21 on some branch for then I did merge and I wonder why that happened.
2:25 Probably I would recommend doing the pr style workflow for this one, but you all can figure it out what works best for you.

Talk Python's Mastodon Michael Kennedy's Mastodon