![]() Now the git log looks something like the following:Īrgh, what a mess. ![]() I can check out that branch, make the change, commit, and push it. Let's imagine someone comments that I've missed something important in the part-1 branch. Then we run into the gnarly side of stacked branches. This all works great, until someone actually reviews part-1 and requests changes. I heavily rebase and edit the commits before creating a PR. For the second PR, for branch andrew/feature-xyz/part-2, I would create a PR requesting to merge to andrew/feature-xyz/part-1, and for the part-3 branch the PR would request to merge into part-2:Įach PR only includes the commits specific to that branch, which makes for a much nicer reviewing experience (IMO).ĭon't think that I just naturally perfectly segment these commits when creating the feature. I can then create a PR for each of those branches:įor the first PR, for branch andrew/feature-xyz/part-1, I would create a PR requesting to merge to dev (in this example). This makes sense when you think of the git graph of the branches: each branch is "stacked" on top of the previous one.įor example, in the following repo I have 6 commits as part of a feature, feature-xyz, and have broken those down into 3 logical units, with a branch for each. This approach, where you have lots of separate branches/PRs which build on top of one another, is called stacked branches/PRs. Creating separate branches and PRs for each unit of functionality makes it easier for people to consume and follow the "story" of the commits. GitHub's PR review pages really don't cope well with large PRs, even if you have "incremental" commits. ![]() This, again, is to make it easier for people to review. The idea is to make it as simple as possible for others to review by walking through a commit at a time.Īs an extension to that, I often create separate PRs for each couple of commits in a feature. I like to create a "story" with my commits, adding bits of a larger feature commit by commit. Especially when you're creating a big feature. This makes working with "stacked" branches a lot easier. In this post I discuss how to use a new Git rebasing feature, -update-refs, which was included in Git 2.38, in October 2022.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |