Hacker News new | ask | show | jobs
by hughesjj 610 days ago
This argument seems weird to me because even without rerere I found myself doing a lot more work managing merge conflicts with git merge instead of git rebase

As a git merge fan, are there any tips or tricks you suggest beyond the stock git experience when doing git merge to minimize the amount of merge conflicts you get?

I found it was especially bad when doing a git merge on a refactor, but I admit it could just be that I abandoned git merge earlier in my career before switching to rebase and never properly learned it

My most common use cases are feature or bug branches with a lifespan between less than one day and up to one month (although I absolutely have some features on pause for even over a year, in which case interactive git rebase and partially squashing WIP commits is my current method of updating)

All this is for repos from literally just me, to a few changes a month between 3 devs, to 5-2 devs doing multiple commits per day, to some open source projects with commits landing every few minutes from multiple devs if it's like a release day

My current biggest issue with rebase is verified commits with GitHub and a bit of guilt for rewriting committed feedback from other authors on my PRs

The only time I really use git merge is when I want to see how my work interplays with more than one feature branch at once, or if the feature branch I want to integrate hasn't rebases themselves in a bit and conflicts occur

1 comments

Most of the time I've encountered two engineers pointing fingers about who is responsible for a bug, it turns out that someone's bad merge transferred the git annotation from one engineer to another.

The first time this happened (that I caught) I had two engineers who were sniping at each other. One was older "Max" and not great at data structure algorithms. The other "Stan" was a decent coder but had a bad attitude and was awful with git. Somehow he thought he could raise his status by getting Max kicked off the team.

I come back from lunch one day and Stan is bitching about a bug in Max's new code that's causing issues. To keep these two from fighting I've been reviewing all of Max's PRs and the line of code Stan is complaining about I know for a fact I checked, and was relieved to see Max got it right the first time. But sure enough, the repo says Max fucked it up.

Twenty minutes of git archaeology later and sure enough, Stan messed up a merge and resolved the conflict wrong, introducing the phantom bug. So I showed him the step by step of my diagnosis and then we had another little talk about using rebase.

That sounds like Stan was rebasing someone else's work though?

And wait was Stan rebasing main?

I mean yeah, in that case it's definitely, definitely wrong to use rebase. In general though I always rebase my feature branch and only then merge it into main. Because it's rebased onto the head of main and thus a linear series of commits, there's no merge conflicts to fix.