Git rebase -I is not that scary

vvinhnx about 4 hours ago 31 commentsRead Article on cachebag.sh

ES version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

82% Positive

Analyzed from 1128 words in the discussion.

Discussion (31 Comments)Read Original on HackerNews

flyingcircus3•about 2 hours ago

After more than a decade of using git, I know that my comfort with rebase, and confidence that I wont make an error I can't undo, comes from knowing that I can always abort. And assuming it wasn't garbage collected, I can always get back to orphaned commits, or the commit before I rebased, as long as I keep their hashes. I can definitely look back on my less confident days as times when I wrongly assumed I was walking a tightrope where screwing up was painful and expensive, and easy to take the wrong path, and abort is the universal solvent to all of that.

I do still find myself tripping up on whether the next appropriate step is to make a commit or continue the rebase, as that is dependent on if you're in a merge conflict or just editing a commit. But even when I get that wrong, and collapse two commits together, abort saves the day.

hetman•14 minutes ago

You don't need to keep their hashes. If you realise too late that things went terribly wrong, you can get the pre-rebase hashes with "git reflog", because git keeps them for you. (It can take a little getting used to knowing how to identify them quickly after a rebase but they're there.)

nixpulvis•about 2 hours ago

I feel like if you're scared of rebasing, you don't actually understand git.

Glyptodon•about 1 hour ago

My fear has never been rebasing itself, but that I make some kind of mistake with a random change conflict and don't notice it because it's not tested for directly. But I'm also not sure if that's categorically a git fear. (Edit: related to this, I think this sort of minor "itchy worry" is grounded in how sometimes conceptually simple diffs look messy during conflict resolution.)

hetman•1 minute ago

If all I'm doing with git rebase is reorganising my commits, and I have to deal with conflicts, after I'm done, I always git diff my pre-rebase head with post rebase head commit hash. I can quickly see I've messed something up if the diff isn't empty. For more complex tasks it's best to leave the rearranging until last, but where not possible, the diff is still pretty useful to double check my work.

jerf•about 1 hour ago

Reflog is, as the article says, the permission to do all kinds of crazy things, including rebasing. Once you realize any committed state is recoverable for a good period of time it really frees you.

Plus you can always take a note of the commit hash before you do anything crazy. But reflog means you don't have to.

Git really does have all the features you need. I wouldn't argue with anyone complaining about the UI to get there. But it's all in there somewhere.

irishcoffee•about 1 hour ago

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.

fleventynine•11 minutes ago

I typically work with commit chains of at least 5 commits in various states of code review, so I spend at least 60% of my development time editing an old commit in the middle of a rebase -i.

maxloh•about 1 hour ago

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...

koolba•about 1 hour ago

That “-I” really needs to be lowercase.

zahrevsky•about 1 hour ago

Someone should collect all the cases when header capitalization on HN affected meaning

Normal_gaussian•about 1 hour ago

Yeah I got quite excited that there was somehow a better -i; its almost perfect clickbait

dietr1ch•14 minutes ago

I was hoping for a rebase that recalled what your previous base commit of your branch.

I'm really not fond of having to `git rebase --interactive` just to drop all commits that are "already in master", especially when I forget this silly step and get a borked rebase.

TazeTSchnitzel•about 2 hours ago

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.

whateveracct•3 minutes ago

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)

throw-the-towel•about 2 hours ago

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

KoleSeise1277•about 1 hour ago

I still make a throwaway branch before a complicated rebase. It costs nothing and turns the whole operation into a low-stakes edit instead of a leap of faith.

russdill•25 minutes ago

Yes, and you can diff the two branches when you are done!

jordanboxer•about 1 hour ago

  git commit —fixup=<commit-id> 
  git rebase -i —autosquash

This is my best friend

tupton•34 minutes ago

Then you will really like:

    git history fixup <commit-id>

https://git-scm.com/docs/git-history#Documentation/git-histo...

BobbyTables2•about 2 hours ago

I also thought rebase was scary long ago. It is scary in the sense if one messes something up without realizing and then pushes to master…

Besides interactive rebase, my other favorite command is “git log —-oneline origin/master..HEAD”

It shows me exactly where I am…

code_lettuce•about 2 hours ago

Big rebase fan here. I find myself using squash the most.

Normal_gaussian•about 1 hour ago

    pick a1b2c3d Add user model
    s e4f5g6h Fix typo in user model
    pick i7j8k9l Add login endpoint
    s m0n1o2p WIP debugging login endpoint
    s feedbee fixed login endpoint
    s deadbee fixed login endpoint
    s adebade fixed login endpoint
    s abcdefg actually fixed login endpoint

Of course, I get reminded about f/fixup every now and then - think "golly, that will save a second or two" and promptly forget.

newsicanuse•about 1 hour ago

I use rebase so much but it only feels comfortable because I follow a workflow while rebasing.

trescenzi•about 1 hour ago

Another git command I love using is `git add -p`. I always want to commit in chunks as I go but sometimes I wait to long or realize later I could have broken it up. Being able to select only pieces of a file to add to a specific commit is so great. Editing the chunks manually can be a bit intimidating but since it only stages the change you can always restore the file and try again if the diff doesn't look right after the add.

nicoburns•about 1 hour ago

That "git add -p" works from the command line is cool, but this is the one git task that I feel is significantly easier using a GUI tool (I use one specifically for this (and viewing diffs) while otherwise mostly using the command line).

sodapopcan•23 minutes ago

I used to feel the same, and I still use a TUI tool, but after working with people who always used the CLI for this (who oddly otherwise were big into IDEs) it's actually an oddly really nice experience and not really any faster or slower. In fact, seeing a hunk at a time has this "focusing" affect on thinking about each change.

Again, though, I still use a visual tool.

cmrdporcupine•about 2 hours ago

I really love the emacs interactive rebase mode, which comes up by default when you have EDITOR=emacs and do rebase -i.

I know you can do this from within magit as well but I've never gotten into that workflow.

skydhash•about 1 hour ago

The nice thing with magit is how easy it is to manipulate hunks and line, truly editing commits with a surgical precision, all with an handful of keybindings.

ks6g10•about 1 hour ago

Even just rebase fixup a commit that is a few commits below HEAD is just a few chords away. Use it many times a week when working.

dionian•about 1 hour ago

sometimes i wish mercurial won, if nothing else for the fact that i found its ux to be more enjoyable. I respect and use git, but never got comfortable with merging. im thankful AI can automate it for me now

jauntywundrkind•about 2 hours ago

rebase interactive is so great, such a powerful tool.

it's the one clear tool that i used all the time. moving to jj, it has lots of amazing tools starting with `jj edit` to go change the past safely & conveniently, with much less pain. but i miss the direct powerful data-driven experience of seeing the timeline in a text file, and picking what to do with it. sometimes.

imo every dev should work to get some competency with git rebase! it's an amazing tool. there's few other systems that give such direct control. it's top layer is, perhaps, the excel of version control?

ed_mercer•36 minutes ago

I cannot recall the last time I committed manually, let alone rebase manually. An agent can do it for you faster and without making mistakes.