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!
Follow the wormhole through a path of communities !webdev@programming.dev
One of the best things I did for my git usage was ditch a gui like SourceTree.
It’s far too easy for it to run an action that is actually running a series of commands under the hood and have git get stuck in the middle somewhere.
I still use gui tools (git extensions) for staging and reverting, but everything else is cli.
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