Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git rebase, what can go wrong

jvns.ca

Post reply on HN
Print view View original

141–150 of 404 posts

Re: Git rebase, what can go wrong

#141

Post by smw »

naasking wrote: post #80
jzm2k wrote: post #58

Earlier quoted context omitted.

git-rebase is stupid because somebody doesn't know how to use it? I use it all the time and I really like how I can make garbage commits (wip, test) and then squash them into atomic commits which are easy to review and later on easy to bisect when inevitably mistakes happen. Sure I've fucked up too when I was learning on how to use it and those were some painful mistakes but only through using it and making those mis…

> git-rebase is stupid because somebody doesn't know how to use it? The whole purpose of source control is to reliably track code changes so you don't lose anything and can revert to any point or recover from bad merges. Since rebase permits you to violate this core purpose and literally lose the entire history of code changes, then yes, it is stupid.

It doesn't. Reflog still exists.

Re: Git rebase, what can go wrong

#142

Post by btilly »

lifeisstillgood wrote: post #126
btilly wrote: post #103

Earlier quoted context omitted.

No, because git bisect operates off of the information in the history. And thanks to the bad rebase, the history no longer existed in the branch.

Just clarifying ... they took a version of master from say a month ago, did their work on it, then, they force pushed their work out, wiping everyone else's work that was added to master since one month ago? I mean that's the equivalent of reversing your JCB through a house on a building site because "the house was not there a week ago when I last moved the JCB". or am I missing something?

Basically equivalent to that. This was about a decade ago.

We had 4 teams, each released on a schedule. Each team had a branch. When a team released, it was merged from master, then each team pulled. The person who did the pull would change, and it was often a rebase.

So my team released, some other team rebased badly. There would be no sign of problems for us until after they released. But since 2 teams generally released at once, and people didn't remember who actually did the merge a few weeks earlier, it was hard to figure out who was actually messing up. (I had suspicions, but no proof.)

I've seen rebase used appropriately since. But that disaster left scar tissue.

Re: Git rebase, what can go wrong

#143

Post by alkonaut »

If I were to write a blog post on this I’d make a few do’s and don’ts (why make a blog post when you can blog in HN comments?)

Don’t merge the base branch into a feature branch. Rebase to “update”.

Do use rerere and the curse of fixing the same conflict over and over is (almost) gone.

Don’t rebase (or force push for other reasons) a shared branch. Rule of thumb here is you can probably rewrite history if you work with _one_ coworker in a branch but any more than that and you’re more likely than not to upset someone.

Do rebase -I HEAD~N to reorder/reword/squash into easily reviewable sequences of commits.

Don’t force push after review, until the review is complete. This keeps the history of the review process but you can later merge the fixups with the commits they logically belong in right before merging.

Do use Merge, Squash and “Rebase+FF” as appropriate for merging PR. There is no best solution for every scenario so prescribing “always merge” or “never merge” or similar isn’t helpful. A good rule of thumb though is that IF a branch has merged from the parent branch to update (which I suggested was a “don’t”) then avoid merging it back. A branch that was updated that way is better to e.g squash when merging back.

Re: Git rebase, what can go wrong

#144

Post by noahtallen »

gray_-_wolf wrote: post #81
diek wrote: post #63

Earlier quoted context omitted.

> destroying Commit information just to keep the graph tidy is a bad idea in my opinion The commit information I see when telling teams to squash their branches on merge is not valuable. * "fixing whitespace" * "incorporate review comments" * "fix broken test" * "fix other broken test" (note, the broken tests were broken by the changes in the PR) As soon as that PR is merged those commits are worthless. And there are…

> * "fixing whitespace" * "incorporate review comments" * "fix broken test" * "fix other broken test" Things like this should not be standalone commits though, they should be incorporated into the previous branch by amending the original work. It takes some effort to have a useful git history, it does not just happen on its own.

You can very easily rewrite your commit message on GitHub when squash merging. Since the organizations I work exclusively use squash merge, I often just update the commit to be more valuable, listing the important changes it contains. (And of course the PR in GitHub will contain the commit history of the branch that was squashed, as well as any discussion.)

IMO, this is a lot simpler and easier to do than rebasing your branch to have a flawless history.

Re: Git rebase, what can go wrong

#145

Post by jawns »

recursive wrote: post #5
jawns wrote: post #2

I like how Atlassian puts it: > The golden rule of rebasing > Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commit…

Squash merges cut down the noise considerably.

My rule of thumb for commits is that they should be of a size and scope suitable for cherry-picking. So, maybe I'm working on a small feature that entails three changes, and each of those three changes is useful in and of itself and could conceivably be cherry-picked by others. I would create three separate commits, generate a PR with all three, and merge in the work. Sure, I could squash merge and end up with one merge commit encompassing all three changes, but now none of those three changes is cherry-pickable.

Re: Git rebase, what can go wrong

#146

Post by b450 »

duped wrote: post #134
AndrewDucker wrote: post #70

I find it fascinating that people talk about "Having a history of what people did" in such emotive terms - "Cluttering", "Polluting". What matters is that you end up with working systems. That a lot of change happened is just, well, what happened. It doesn't need to be prettied up and made to look like your development occurred in a clockwork march of cleanliness. It literally does not matter unless you spend a lot o…

The point of a clean git history is not to have a clean git history. The point is to make it possible to debug later, via bisect, or show, or even just a diff. The point is to make the workspace clean for the next guy. Instead of letting it go, maybe we should have more discipline and organization in our lives and not less.

Did you notice, though, that rebase advocates use very "emotive" terminology when talking about git history? Like it's a subject they care about? Seems awfully touchy feely.

Re: Git rebase, what can go wrong

#147

Post by mattbillenstein »

There are just too many things you have to know about which commits are what and what's going on - especially with a larger team - it's not a good use of time imho to be fixing rebases when they go wrong. Like the big list of dos and don'ts at the end of this should be a red flag.

Better alternative I've found is squash merge - topic/feature branches are squashed as a single commit instead of bringing down each individual commit or creating a merge commit. You're history is cleaner, you're able to revert stuff easily, and it's really hard to mess up since it's just an atomic last step you do in your workflow.

Re: Git rebase, what can go wrong

#148

Post by mablopoule »

diek wrote: post #56
mablopoule wrote: post #13

Earlier quoted context omitted.

I actually hate squash merge because of all the noise it adds. Sure, the commit graph looks nicer, but it come with a terrible loss of information when doing git blame. I'm a big proponent of rebase and squash if it helps to make a commit more coherent, but we use squash merges by default in the current project I'm working on, and I die a little bit each time I try to understand what changes were related to a line wh…

> I die a little bit each time I try to understand what changes were related to a line when tracking down a bug A change/feature/bug is a branch, which is squashed into a commit on your main branch, right? So your main branch should be a linear history of changes, one change per commit. How does that impact the ability to git blame?

Because now instead of having a line changed within a granular level of changes, it's lost with the other changes from the same feature branch, which is a more macro level. So if a change in config is needed for the feature, the part when this config change actually need to be handled, or would impact the data-flow is harder to evaluate now that you mix it with template changes, style changes, new interactions needed for the users, etc...

EDIT: On top of that, there's usually a bit of 'related' work you need for a task, by example when you find an edge case related to your feature, and now you also needed to fix a bug, or you did a bit of refactoring on a related service, or needed to change the data on a badly formatted JSON file.

Unbeknownst to you, you added a bug when refactoring the related service, a bug that is spotted a few months after, only on a very specific edge case. If the cause is not obvious, you might want to reach for git bisect, but that won't be very useful now that everything I've talked about is squashed into a single commit.

Re: Git rebase, what can go wrong

#149

Post by [deleted] »

joshribakoff wrote: post #123
dkarl wrote: post #92

Earlier quoted context omitted.

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature. But since you're working on the fly with…

You can simply ask “git log” to show you one coarse entry per Pr rather than “destroying” the more granular history

[deleted]

Re: Git rebase, what can go wrong

#150

Post by phinullfermata »

mvdtnz wrote: post #93
phinullfermata wrote: post #62

Uising squash merges has reduced my need to rebase a lot. I don't really care if I have merge commits on a feature branch for a PR if there's a reasonable history on the main branch when I'm troubleshooting an issue with git blame. Why squash merges? I have a number of team-mates who make local commits on feature branches that make the history look like a series of less-than-useful commit messages. E.g. wip, wip, wip…

Squash merges are rebases.

Maybe under the hood, but it's an option on github if you use that, or you can run `git merge --squash` as well.
Post reply on HN