Top 5 themes from the discussion
| # | Theme | Key points & representative quotes |
|---|---|---|
| 1 | Rebase vs. Merge – the “clean‑history” argument | • “I wish rebase was taught as the default … it’s honestly easier to reason about a rebase than a merge since it’s so linear.” – coffeebeqn • “The end result of a git rebase is arguably superior.” – Akranazon • “Rebase only makes sense if you’re delivering stacked PRs.” – PaulDavisThe1st |
| 2 | Tooling friction & workflow pain | • “Rebase is a complete hassle … you have to remember what was going on a week ago.” – Akranazon • “Git is finicky. It requires more from its user than most tools do.” – teaearlgraycold • “I don’t have time for the judgement.” – Akranazon • “You need a UI that shows you the commit you’re on and the incoming change.” – Groxx |
| 3 | Preserving vs. discarding history | • “I’m fine with manually squashing individual “fix‑typo” commits, but just squashing the entire branch removes too much.” – Izkata • “The key thing to point out is that jujutsu is a rebase‑based workflow … no one worries about rebasing.” – BeetleB • “If you squash the entire branch you lose the intermediate commits that have had extra context.” – Izkata |
| 4 | Safety, recovery, and fear of loss | • “Git rebase can destroy work … you can’t undo it.” – rich_sasha • “The reflog is a good way to recover from a bad rebase.” – nh2 • “You can just branch off before rebasing and keep a backup.” – DHRicoF • “I’ve lost work via rebase; I prefer to keep the branch around forever.” – rich_sasha |
| 5 | Use‑cases that influence the choice | • “Rebase helps when you have many feature branches in progress – you only have to resolve conflicts once.” – nicoburns • “Git bisect works better with a linear history.” – MatrixMan • “Squash merges keep the main branch clean and make CI easier.” – freeplay • “Long‑lived branches with frequent rebases keep the diff small and the merge fast‑forward.” – just6979 |
These five themes capture the core of the debate: whether to favor a linear, rebased history or a more natural merge‑based one; how tooling and workflow friction shape that choice; whether to preserve every commit or squash them; how to mitigate the fear of losing work; and which real‑world scenarios (debugging, CI, PR review, long‑lived branches) tip the balance.