Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Git rebase isn't scary at all, what's scary is the git rebase cult. I'll probably die never really seeing the tangible benefit a meticulously curated git history provides but at least I saw a few hundred blog posts and hn comments declaring the moral failure that is not having the cleanest commit history. The cynic in me would say that people are over-identifying too much with their recent bikeshedding addiction (just like 10-page vim configs, custom built keyboards or whatever else promises them immense but immeasurable performance gains) but in reality I guess it's just completely different mental models about code. I have yet to look at any code or it's however dirty history and needed to consult a commit message to understand what it's there for but I'm looking forward to the day where one of my rebase colleagues fixes a bug with git bisect that wasn't efficiently fixable any other way.
    by fisensee
  • I use git history to understand wtf my colleagues, and myself, where doing and thinking 10 years ago. A well structured, squashed commit and a clean history helps A LOT. I can't tell you how often I find a 'Apply review changes' and 'Fix shit' commit with no context. I then need to go back in the blame history or find what branch/PR this belonged too on GH to find even the context of these changes. Perhaps you don't work on the kind off crappy code bases I am dealing with, but a bit of git discipline saves a fuckton of frustrations.

    tbf, this says a lot more about the code base, my colleagues and the shitty, lazy culture at our company that leads to ZERO ownership and architecture ;)

    by boesboes
  • I fix bugs will git bisect all the time. But it’s not practical if you don’t have a good commit history to begin with.
    by geon
  • People are different, and I think we have to respect that. In my role I tend to have to fix problems in other people's code probably on a weekly basis. Commits that do too much, or too little, or are generally hard to understand are the number one reason this takes time. Crafting readable commits takes seconds out of your work day. Please be considerate to all your future colleagues.
    by xorcist
  • I continual find the amount of ink spilled on having a clean commit history amazing, when you can basically get all the same benefits with:

    git log --first-parent

    git bisect --first-parent

    by mikeocool
  • A workflow I was introduced to and have worked with a lot in my teams is,

    1. Everyone uses feature branches

    2. Everyone cleans up their branch using interactive rebase on top of main before review

    3. All merges have been freshly rebase on main

    I think it works very well and keeps the history clean while preserving "each commit does one thing".

    by zith
  • I worked on a team that did this, + required feature branches to get squashed to a single commit before merge. On that commit, we'd require a very brief bullet list of changes, sometimes a POC, and a link to the PR. This made git blame a lot more helpful when debugging issues. I am a big fan of this approach.
    by skitsofrandom
  • I wish my team would at least use the rebase merge strategy by default to avoid branch graphs looking like the London tube network. Not in 10 years did I have an issue with that (okay, except accidentally rebasing deliberate no-ff merges).

    The one time I suggested that, someone immediately came up to me trying to convince me that rebases are the most dangerous thing ever.

    by mr_mitm
  • The HN title is "Git rebase -I etc" but the post title is "Git rebase -i"

    I guess a keyboard auto corrected i into I.

    by pmontra
  • I wish there were a shorthand for

      x git commit --amend --reset-author --no-edit
    I use that one very frequently (after a fixup, of course) because I want the author date on amended commits to reflect the last time I edited them, not the first time I committed them.
    by TazeTSchnitzel
  • i edit my commit dates constantly for various reasons

    get ahead at work? split into commits and make it look like multiple days of work

    work on your own IP during work hours? edit the timestamp to be outside work hours (i even have a script for this)

    by whateveracct
  • But you can make your own alias?

      > git config --global alias.whatever_you_want 'commit --amend --reset-author --no-edit'
    https://git-scm.com/book/ms/v2/Git-Basics-Git-Aliases
    by throw-the-towel
  • One additional thing I would mention ist that: When resolving conflicts never try to solve them for the final result. Consider each conflict without considering how the code will change in a later commit. I’ve seen people die a painful rebase death because of this.
    by LunicLynx
  • rerere
    by formerly_proven
  • Yeah like the other commenter below mentioned, `rerere` takes a lot of the pain out of layering rebased changes. It's important (IMO) to make sure each commit still contains a logical change and a working system, even with an incremental rebase.
    by chrysoprace
  • I found the VS Code GitLens extension to be a good abstraction for interactive rebase. It provides a drag-and-drop UI with a dropdown to select actions applied to each commit. That is much easier than editing a text file.

    Here's a GIF I found with Google: https://yogwang.site/2025/cursor-vscode-gitlens-rebase-edito...

    by maxloh
  • Oh that's really very clean, yeah. It's almost literally exactly what's in the text editor, just with a more friendly-for-mouse UX. They did very well.
    by t-writescode
  • I'm a big fan of https://github.com/MitMaro/git-interactive-rebase-tool on the terminal.

    I also use git absorb (https://github.com/tummychow/git-absorb) and lazygit a lot (https://github.com/jesseduffield/lazygit).

    by QGQBGdeZREunxLe
  • That “-I” really needs to be lowercase.
    by koolba
  • And, ironically, a lot of letters in the blog post need to be uppercase.
    by TurboSkyline
  • Yeah I got quite excited that there was somehow a better -i; its almost perfect clickbait
    by Normal_gaussian
  • Someone should collect all the cases when header capitalization on HN affected meaning
    by zahrevsky
  • Why isn't the 'edit' command mentioned? It's one of the most useful features. It can be used for splitting commits, for example. Mark the commit you want to split to be edited. The commit replay is going to stop after that commit. Now:

      git reset HEAD^1 (NO --hard!)
  git commit --patch ...
  git rebase --continue
    You want to add some pending changes to the previous commit? No problem:

      git commit --patch --amend ...
    You want to move the pending changes to future commits?

      git stash
  git rebase --continue
  git stash pop
    by pajko
  • I think these esoteric workarounds required for what are trivial operations is why people use Jujutsu, which just has first-class "new", "squash" and "split" commands which can do all of the above intuitively, and more. Even more so if you use `jjui`.

    (jj of course has its own warts as well)

    by jaen
  • I feel like if you're scared of rebasing, you don't actually understand git.
    by nixpulvis
  • Correct on both counts.
    by LAC-Tech
  • I'm not scared of rebasing I'm scared of force pushing
    by Kuraj
  • This notion that `git rebase -i` is some scary unusual thing is totally alien to me. Doing some minor cleanup on local history with rebase is a *basic* operation that I would have thought everyone would be using regularly.
    by harpiaharpyja
  • When I interview someone and they are scared of `git rebase -i` it's a huge red flag.

    Git rebase has such foundational data structures and concepts that you couldn't pass a serious college programming course without grokking it.

    The only reason someone would be scared of git rebase is:

      a) they don't know the basics of programming/software engineering
  b) they are not intellectually curious enough to look into how tf the software they use every day works
    You probably shouldn't have engineers like that on your team.
    by avaer
  • The part where git needs to be “understood” is the entire problem. “Do one thing and do it well” was the whole mantra, which was completely ignored with the disaster that is git. It’s objectively awful.
    by irishcoffee