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.