Hacker News Reader

Comment by sidlls | Hacker News Reader

Git is in general a terrible tool: I’ve always thought of it as a shining example of where “worse is better” ought to have been applied. Rebasing is one of its worst features. For non-trivial changes, anyway, it is often just a way to add complexity and messiness to what should be a simple workflow. And the benefits aren’t at all as clear as its advocates contend.

View on HN

Yes, and these folks are never around when you try rebase and get a forty file conflict and have no idea how to get out. Happened to me several times when I fell for one of these articles.

You know what works almost every single time? With tiny conflicts if any? Merge + squash on gitlab.

If a rebase goes wrong and you want out you can run,

  git rebase --abort

to return to where you were beforehand.

I find that git is actually very good at explaining what is going on and what you should do next by just running git status in the middle of some process like rebasing and reading what it says.

Even if it all goes really wrong the git reflog has always saved me.

Ok, but what do you do when it goes wrong every single time you've tried it? That's what happens at work, so I gave up and use merge+squash on gitlab.

Yep. And most of the time conflicts merging from master into your working branches produces minimal conflicts.

Rebasing is just a way to make extra work for yourself

1) Never use rebase on the master branch.

2) Before you rebase take a note of your current branch's HEAD commit.

3) If things go horribly wrong, you can force your branch to point at the original commit and it will be as if nothing happened. Well as long as you do it immediately. At some point git gc will collect up unreachable commits and delete them.

Reply on news.ycombinator.com