Git Rebase for the Terrified

Post by xlii » Tue, Jan 13, 2026, 9:15 AM UTC

ongy wrote: post #6

thibaut_barrere wrote: post #4

PSA: I’m not terrified of rebase, yet it’s good to know this: https://docs.github.com/en/get-started/using-git/about-git-r... > Warning - Because changing your commit history can make things difficult for everyone else using the repository, it's considered bad practice to rebase commits when you've already pushed to a repository. A similar warning is in Atlassian docs.

I think a large part of this is about how a branch is expected to be used. Branches that people are expected to track (i.e. pull from or merge into their regularly) should never rebase/force-push. Branches that are short-lived or only exist to represent some state can do so quite often.

Post by teaearlgraycold » Tue, Jan 13, 2026, 9:29 AM UTC

Akranazon wrote: post #3

coffeebeqn wrote: post #2

I wish rebase was taught as the default - I blame the older inferior version control software. It’s honestly easier to reason about a rebase than a merge since it’s so linear. Understanding of local versus origin branch is also missing or mystical to a lot of people and it’s what gives you confidence to mess around and find things out

The end result of a git rebase is arguably superior. However, I don't do it, because the process of running git rebase is a complete hassle. git merge is one-shot, whereas git rebase replays commits one-by-one. Replaying commits one-by-one is like a history quiz. It forces me to remember what was going on a week ago when I did commit #23 out of 45. I'm grateful that git stores that history for me when I need it, but…

Post by cousin_it » Tue, Jan 13, 2026, 9:39 AM UTC

jillesvangurp wrote: post #10

coffeebeqn wrote: post #2

I wish rebase was taught as the default - I blame the older inferior version control software. It’s honestly easier to reason about a rebase than a merge since it’s so linear. Understanding of local versus origin branch is also missing or mystical to a lot of people and it’s what gives you confidence to mess around and find things out

Rebase your local history, merge collaborative work. It helps to just relabel rebase as "rewrite history". That makes it more clear that it's generally not acceptable to force push your rewritten history upstream. I've seen people trying to force push their changes and overwrite the remote history. If you need to force push, you probably messed up. Maybe OK on your own pull request branches assuming nobody else is wo…

Post by ngruhn » Tue, Jan 13, 2026, 9:42 AM UTC

hnarn wrote: post #15

ngruhn wrote: post #13

Maintaining linear history is arguably more work. But excessively non-linear history can be so confusing to reason over. Linear history is like reality: One past and many potential futures. With non-linear history, your past depends on "where you are". ----- M -----+--- P / ----- D ---+ Say I'm at commit P (for present). I got married at commit M and got a dog at commit D. So I got married first and got a Dog later,…

> So I got married first and got a Dog later, right? No. In one reality, you got married with no dog, and in another reality you got a dog and didn't marry. Then you merged those two realities into P. Going "back in time to commit D" is already incorrect phrasing, because you're implying linear history where one does not exist. It's more like you're switching to an alternate past.

Post by vlovich123 » Tue, Jan 13, 2026, 9:44 AM UTC

xlii wrote: post #11

Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement. In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained t…