this post was submitted on 03 Nov 2023
63 points (98.5% liked)
Programming
17514 readers
274 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
git rebase --onto
is great for stacked branches when you are merging each branch using squash & merge or rebase & merge.By "stacked branches" I mean creating a branch off of another branch, as opposed to starting all branches from
main
.For example imagine you create branch A with multiple commits, and submit a pull request for it. While you are waiting for reviews and CI checks you get onto the next piece of work - but the next task builds on changes from branch A so you create branch B off of A. Eventually branch A is merged to main via squash and merge. Now main has the changes from A, but from git's perspective main has diverged from B. The squash & merge created a new commit so git doesn't see it as the same history as the original commits from A that you still have in B's branch history. You want to bring B up to date with main so you can open a PR for B.
The simplest option is to
git merge main
into B. But you might end up resolving merge conflicts that you don't have to. (Edit: This happens if B changes some of the same lines that were previously changed in A.)Since the files in main are now in the same as state as they were at the start of B's history you can replay only the commits from B onto main, and get a conflict-free rebase (assuming there are no conflicting changes in main from some other merge). Like this:
The range
A B
specifies which commits to replay: not everything after the common ancestor between B and main, only the commits in B that come after A.That is a much better explanation than the manual. This is the first time I get it.
Wow that actually sounds really helpful. Didn't know you could do that. As always, best content in the comments