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

Don't use Git rebase

medium.com

Post reply on HN
Print view View original

71–80 of 88 posts

Re: Don't use Git rebase

#71

Post by jmah »

nunez wrote: post #70

Rebase is incredibly useful for me because I commit on every save and squash my commits before submitting for PRs (if working on a team). I commit on every save for three reasons: 1. I can easily undo small mistakes this way, 2. It makes it easy for me to pick up what I've done the last time I worked with that codebase, and 3. It makes it easier for me to tell a comprehensive story when I'm ready to submit my PR. Tha…

"rebase" (like many terms in git) has multiple implications. It sounds like you're advocating for squashing your commits / cleaning up your history, which I don't think anyone argues against. The linked post argues against re-parenting those changes.

Re: Don't use Git rebase

#72

Post by scarlac »

chrisjshull wrote: post #69

I'm really surprised no one (article included) has brought up the "Golden Rule of Rebase" ( https://www.google.com/search?q=golden+rule+of+rebase ), which boils down to "never rebase a shared branch". Git is an extremely powerful tool for collaboration, and it's frustrating when I see that undermined.

The rule makes a lot of sense but most of the articles I found completely ignore if this includes systems like GitHub or Bitbucket. Technically you can create a Pull Request based on the branch yet no-one is actually "using" it. Would you say the rule also applies to such a branch?

Re: Don't use Git rebase

#73

Post by closeparen »

rout39574 wrote: post #12
thibran wrote: post #4

There is a third option nobody seems to talk about `git merge --squash` (a squashed commit bundles commits into one commit). Which produces like `rebase` a linear commit history, but preserves the single commits.

I would think squash a poor default policy; it destroys information in the granularity of commit, and in the commit messages.

If you use rebase or squash merge with something like Phabricator, you can always open up the Diff URL in the commit message and see the granular history (and discussion) if you care to.

Re: Don't use Git rebase

#74

Post by chrisjshull »

scarlac wrote: post #72
chrisjshull wrote: post #69

I'm really surprised no one (article included) has brought up the "Golden Rule of Rebase" ( https://www.google.com/search?q=golden+rule+of+rebase ), which boils down to "never rebase a shared branch". Git is an extremely powerful tool for collaboration, and it's frustrating when I see that undermined.

The rule makes a lot of sense but most of the articles I found completely ignore if this includes systems like GitHub or Bitbucket. Technically you can create a Pull Request based on the branch yet no-one is actually "using" it. Would you say the rule also applies to such a branch?

I would. A common thing I like to do is start working on top of work that's in a Pull Request. For example, maybe a coworker is adding an API that I want to use. So long as I'm confident the API won't have drastic changes, and there's just smaller polish or testing to be added, I can branch off of their branch and start working without delay. This also gives me a window to live on top of the changes and give feedback from usage even faster (maybe even before it officially lands).

Re: Don't use Git rebase

#75

Post by yyparm »

Vinnl wrote: post #29
fulafel wrote: post #2

What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing. Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity…

There's no such thing as "real" history - you don't commit every line of code you add or remove, or even every character. Rather, you choose some points in time to commit. For me, those are often arbitrary - I can't get something to work at a certain point, so I make a WIP commit with the buggy work at that point, and will come back to it the next day. Before I merge my branch back into master, though, I want my comm…

This makes a lot of sense to me. If you're maintaining a large project having lots of non-cohesive commits make it much harder to figure out what the logical changes were. I care about the set of code changes that were required to add a feature or fix a bug. I don't care about the set of changes that were required to get halfway to working code.

This is also potentially a big deal if you're doing maintenance bugfix releases for a project - that's way easier if porting the bugfix to an older branch just requires cherry-picking a single commit.

Re: Don't use Git rebase

#76

Post by SOLAR_FIELDS »

yyparm wrote: post #75
Vinnl wrote: post #29

Earlier quoted context omitted.

There's no such thing as "real" history - you don't commit every line of code you add or remove, or even every character. Rather, you choose some points in time to commit. For me, those are often arbitrary - I can't get something to work at a certain point, so I make a WIP commit with the buggy work at that point, and will come back to it the next day. Before I merge my branch back into master, though, I want my comm…

This makes a lot of sense to me. If you're maintaining a large project having lots of non-cohesive commits make it much harder to figure out what the logical changes were. I care about the set of code changes that were required to add a feature or fix a bug. I don't care about the set of changes that were required to get halfway to working code. This is also potentially a big deal if you're doing maintenance bugfix r…

This is precisely why we rebase and squash. We maintain about 4 release branches at any given point and having everything squashed into one or two commits makes a bug fix on master simple and straightforward to downstream.

Although more frequently what we will do is do the bug fix on the furthest downstream branch and because we tag our branches with semver scheme we jus have our prep-for-deploy build automatically walk back up the branches back to master and attempt to merge the feature in along the way.

Re: Don't use Git rebase

#77

Post by yyparm »

I tend to think the problem identified by the author is more of a fundamental problem with long-lived development branches that diverge with master - stuff will change under you and it's not always easy to notice.

It's also kind of a problem if underlying parts of the system that you depend on either are churning that much without that being communicated or if they have poorly-defined interfaces and are prone to accidentally breaking things that users depend on.

It's not entirely clear, but there may be some testing gaps too if bugs weren't found.

Maybe merge-based workflow helps a bit but it seems like the pain would still be there regardless.

Re: Don't use Git rebase

#78

Post by lostmsu »

Ballantara wrote: post #59
golergka wrote: post #49

Earlier quoted context omitted.

But that's exactly why I prefer merges - seeing that the problem wasn't in any individual branch, but resulted from the combination of changes in both is the most honest result that I would've wanted to see. Why do you label this as a 'failure'?

It sounds like rebasing this way ensures branches will not overlap at merge time. This presumably pushes the "combination of changes" into the rebased-before-merging branch, which (if nothing else) makes sure that one committer owns the bug, not two.

In case of merge that would be merge commit author.

Re: Don't use Git rebase

#79

Post by joshuamorton »

kstenerud wrote: post #63
andrewaylett wrote: post #24

`git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I'm a big fan of Gerrit's review workflow, which requires every commit to build in isolation. I also usually try to squash my changes into logical independent commits before review. I like rebase because it's prettier, but I also think there's an issue with the non-rebase case that the OP has missed: unless you rebase, you're setti…

This would probably be ok for smaller projects. My current codebase takes an hour and a half to build, so a rebase to master will involve anywhere from 10 to 100 rebuilds (1-10 days worth), not to mention the whole process stopping on each merge conflict, which will stretch out the rebase time even more as Murphy's Law will place every conflict outside of working hours.

What are you doing where a build takes that long (and can't be done incrementally)?

Re: Don't use Git rebase

#80

Post by anonred »

tekacs wrote: post #35
shock wrote: post #19

> Graphs of non-linear history, “train tracks”, can be intimidating. They certainly felt that way to me to begin with, but there’s no reason to be scared of them. There are many magnificent tools that can analyse and visualise complex Git history, both GUI- and CLI-based. It's a pity the author doesn't mention some of those magnificent tools. Some tools I know/use: CLI: tig GUI: gitg, qgit (Linux) Any others?

For Mac users, there's http://gitup.co/ (I'm not affiliated and it's FOSS). GitUp is beautiful, incredibly fast and you operate directly on the (well laid-out) graph for almost everything, so you're always acutely aware of the commit history. (I mostly use Windows + Linux at the moment and this is probably the piece of software I miss the most, even though I prefer shell for absolutely everything else)

+1 for GitUp. Only annoyance is that it can be slow when staging/unstaging lots of files.
Post reply on HN