![]() The "during development" scenario doesn't only happen during development, and the "during review" scenario doesn't only happen during review. Shorter… but requires more knowledge of the context.) A new era # (Or git rebase -onto first first~ third-requires-second. With git rebase -update-refs we can instead run one command git rebase -fork-point -update-refs third-requires-second Git rebase -fork-point second-requires-first third-requires-secondįollowed by pushing first and force pushing ( -with-lease!) second-requires-first and third-requires-second. ![]() ![]() Or my preference before git rebase -update-refs, git rebase -fork-point: git rebase -fork-point first second-requires-first Git branch -f second-requires-first third-requires-second~ We could run git rebase -onto first first~ third-requires-second To get to the goal A(main) < goes-before-B < B < E(first) < C(second-requires-first) < D(third-requires-second) Which would leave me at A(main) < goes-before-B < B < E(first)Ĭ(second-requires-first) < D(third-requires-second) In the past, I might have added a commit to that branch git checkout first Say a colleague requests a change in the first pull request. Pull request 3: second-requires-first ← third-requires-second.Pull request 2: first ← second-requires-first.Say I put these branches up for review at the same time (this isn't a standard Viget practice but our process is okay with it, and it comes up from time to time). The second real-life is during the review/approval phase. Which results in A(main) < goes-before-B < B(first) < C(second-requires-first) < D(third-requires-second) With Git v2.38, my solution is git rebase -interactive -update-refs first~ Maybe git-log or a Git graph UI to figure what B' and C' are relative to third-requires-second, or to look up their IDs, and then some git reset -hards or git branch -fs. Git surgery is required to point first to B' and to point second-requires-first to C'. Which would result in A(main) < goes-before-B' < B' < C' < D'(third-requires-second) I'm at A(main) < B(first) < C(second-requires-first) < D < goes-before-B(third-requires-second)Īnd want to be to A(main) < goes-before-B < B(first) < C(second-requires-first) < D(third-requires-second)īefore Git v2.38 my solution was # Step 1. I'm working at third-requires-second and make a change that belongs in first. (I'm keeping each branch to only one commit for legibility.) A(main) < B(first) < C(second-requires-first) < D(third-requires-second) Maybe they are for dependent features maybe it's one large feature, and I'm splitting it up to make code review more feasible. I sometimes build several branches upon each other. The first real-life scenario is during development. ![]() I'm excited about this enhancement because of two scenarios I run into: Here's the difference: A < B(main)įollowed by git rebase -update-refs main feature With -update-refs, git-rebase will also update all branches which start out pointing to commits that then get rebased. Results in A < B(main) < C' < D'(feature) Here's what happens in a multi-branch situation with a standard rebase: A < B(main) But what if there are intermediate branches between the specified branch's fork point ( A in the above example) and the branch you're rebasing? The new capability # or the convenient form git rebase main feature- results in A < B(main) < C < D(feature) Rebasing C off B - for example with git checkout feature To get the latest, you can use Homebrew: even if you haven't installed Git with Homebrew before, you can run brew upgrade git.Ī standard rebase results in up to one branch pointing at a different commit than it did before A < B(main) To see your Git version, run git -version. With -update-refs, rebasing will "Automatically force-update any branches that point to commits that are being rebased" ( docs). In version Git v2.38 (released Oct 3 2022), git-rebase learned a new -update-refs option.
0 Comments
Leave a Reply. |