![]() ![]() You can use git rebase -update-refs today. But with git rebase -update-refs the solutions are identical □ By adopting git rebase -update-refs you reduce the set of branch management problems you need to have solutions for. But without git rebase -update-refs it is reasonable to think of them as closely related but distinct problems. 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. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |