Don't use Git rebase

`git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I&#x27;m a big fan of Gerrit&#x27;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.<p>I like rebase because it&#x27;s prettier, but I also think there&#x27;s an issue with the non-rebase case that the OP has missed: unless you rebase, you&#x27;re setting yourself up for failure in the `git bisect` case: when you step back to find the source of an bug you&#x27;re tracking down, the worst possible case is that you find it&#x27;s introduced by a merge and not present in either of the parents. That&#x27;s much more likely if your merge commits contain fix-ups of their own, which in turn is much more likely if you&#x27;ve got overlapping branches. If you rebase-and-merge then the merge won&#x27;t have any extra changes, and if you rebase-and-fast-forward then you won&#x27;t have any merge commits at all.

There&#x27;s a more nuanced approach to git rebase. You should use it the other way around - switch to your feature branch and `git rebase master` to update your branch and resolve conflicts. Then test it and `git merge`. I also use git rebase to tidy up the branch&#x27;s history - generally not entirely squashing it, though.

What&#x27;s even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing.<p>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 to revisit conclusions from debugging or experiments.<p>You can also use merge commits to describe sub-units of work in your feature branch. Just rename your branch to some subtask and merge that into your feature branch.<p>edit: towards the middle of the article, the author also opines &quot;What motivates people to rebase branches? ... I’ve come to the conclusion that it’s about vanity. Rebasing is a purely aesthetic operation. The apparently clean history appeals to us as developers, but it can’t be justified, from a technical nor functional standpoint.&quot;

I like rebase. Because to me, git is more about communicating changes to other people than finding bugs. Just like testing is as much communicating intent to other developers as preventing new bugs.<p>So we rebase, and we merge with merge commits. This way, the developer are forced to resolve conflicts one by one on their own branch, instead of sorting out a huge pile in one go on a shared branch.<p>What I like about git, though, is that you can choose different approaches. Discuss in your team what you find important and use git to support that. If finding bugs with bisect is your main thing, use git in a way that makes that as easy as possible. If your have other needs, you&#x27;ll have to find other ways of using the tool.<p>Learning and understanding the tool to use it in the best way to satisfy your needs.

This seems like a knee jerk reaction because a co-worker&#x27;s sloppy rebase caused you to waste a day.<p>This highlights a bigger issue, many people don&#x27;t learn their tools well enough.<p>I&#x27;ve been teaching my fellow senior engineers how to use git the last six months because they&#x27;ve only been using git GUIs until then. They&#x27;re terrified of merge conflicts and they often make mistakes fixing them.<p>I&#x27;d rather educate people and let them make their own decisions once they can understand and justify the tradeoffs.

Doesn&#x27;t squash and rebase eliminate this problem? It removes all those possibly broken intermediate commits once it&#x27;s in master.<p>I&#x27;ll add that another annoying thing about rebasing is that if you make multiple changes to the same piece of code that conflict with changes on master, when you rebase, you have to resolve each change independently instead of only the last snapshot. However, if the changes are in different places, I like the incremental conflict resolution process of rebasing instead of the one-shot merge commit.

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.

In addition to squashing commits, you can merge with `--no-ff` to create s merge commit and semi-linear history showing when new code arrived.

At least part of the arguments against rebase are arguments <i>for</i> feature branches. Keep master forever and rebase your feature&#x2F;bug branches, I would rather say. E.g bitbucket has features for this too - prohibit force push on master&#x2F;release branches, allow on dev branches.

<i>There are many magnificent tools that can analyse and visualise complex Git history, both GUI- and CLI-based.</i><p>Just tell me one. All git tools I know do such a terrible job at this.

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

I tend to use rebase solely for the purposes of creating tidy commits before I merge my changes into a staging branch.<p>For example when I&#x27;m working on a feature I tend to do n things at once, but I then want to create logical commits which separate the work into logical unit which could be reverted etc. as necessary. If in this process I notice that I&#x27;ve forgotten something (or for that matter, realise later than I&#x27;ve introduced a bug &#x2F; broken tests) I&#x27;ll tend to create a patch commit for that logical unit and then `git rebase -i HEAD~n` and then fixup that patch into the original commit.<p>Also, whenever I&#x27;m done for the day instead of stashing I: `git commit -am &quot;wip&quot;; git push; git reset HEAD~1 --soft` (i.e. push my changes up to Origin to avoid any localized mishaps with my PC resulting in a loss of work). I then force push to my feature branch.<p>I know that both of these &quot;change history&quot;, but as long as they&#x27;re isolated to my own feature branches I see no reason to avoid doing so...

&gt; Consider the case where a dependency that is still in use on feature has been removed on master. When featureis being rebased onto master, the first re-applied commit will break your build, but as long as there are no merge conflicts, the rebase process will continue uninterrupted. The error from the first commit will remain present in all subsequent commits, resulting in a chain of broken commits.<p>Easy, just fixup the commit that (re)introduced the dependency.<p>&gt; You pretend that the commits were written today, when they were in fact written yesterday,<p>The author and committer dates will differ accordingly.

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:<p>1. I can easily undo small mistakes this way,<p>2. It makes it easy for me to pick up what I&#x27;ve done the last time I worked with that codebase, and<p>3. It makes it easier for me to tell a comprehensive story when I&#x27;m ready to submit my PR.<p>That said, I do see the authors point about rebasing onto a branch with dependencies.

&gt; 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.<p>It&#x27;s a pity the author doesn&#x27;t mention some of those magnificent tools. Some tools I know&#x2F;use:<p><pre><code> CLI: tig GUI: gitg, qgit (Linux) </code></pre> Any others?

this is a narrow view based on someones versioning habits , the point of rebase can also be a solid linear history that allows multiple teams to fork and pull request features between forks. If developer chooses to play merging inside his own repo, fine but as soon as you have large teams working on their own you will end up in merging hell between developers and teams.<p>say team a does 58 commits per day has 75 team-members and team b has 126 members that are doing 187 commits per day and there&#x27;s team c, d , e .... n giving non conflicting input to your codebase.<p>the flow in this case would be to always rebase developer specific features on non-conflicting codebase before you are allowed to pullrequest your changes to central repo. Rebasing to master or to any feature branch developer needs to work will allow them to see any conflicting changes they have made directly in their repo (rebase conflicts and a way to solve those as they know what conflicts, they have introduced the conflicts) instead of merging it together and finding out that the repo they need to PR this stuff will utterly fail cause they are lagged behind or several developers have changed the same files.<p>in this case rebase flow brings the shit to developer to handle and gives them knowledge that it will break. This mainly happens cause they are not having the latest version of code whereas merge strategy will merge in the conflict and send it to others to discover that thy can&#x27;t merge any more cause of other developers conflicts.<p>Merge strategy is not suitable in case where code is edited rapidly daily and some features take , weeks, years, are to be included. Whereas rebase strategy ensures that every developer will always send you changes that are not conflicting with up to date version of whatever is versioned.

I vehemently disagree. A counter-argument to his `git bisect` problem is whenever I do `git bisect` and I end up on the merge commit being the culprit. At that point I want to cry, because merge commits tend to be ungrokkable — there is so much noise in them.<p>Also, don&#x27;t even get me started on `git revert`ing merge commits... Down that road lies sadness and disillusion.

If you want every commit to compile then have your CI system check this; no need to blame a useful tool.

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&#x27;s not always easy to notice.<p>It&#x27;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.<p>It&#x27;s not entirely clear, but there may be some testing gaps too if bugs weren&#x27;t found.<p>Maybe merge-based workflow helps a bit but it seems like the pain would still be there regardless.

I liked the style of writing, but the lack of knowledge of the author made me create this account and adding my first hn comment.<p>Thanks to all others who explained technically what upset me so much.

Odd, I would rebase develop onto my feature, resolve conflicts which is easier as I&#x27;m dealing with my changes, then merge to eg develop. When time comes for integration I&#x27;d probably squash commit changes to the integration branch just to keep that a bit easier to track&#x2F;undo, but preserve full history in my feature and develop branches do can revert specific commits etc. As always useful comments are a must so I disable automated merge commits.

When using `git bisect` to find a bug, `git bisect good` and `git bisect bad` are not the only options available, there&#x27;s also `git bisect skip`. You should only mark as bad commits that specifically manifest the bug you&#x27;re looking for and not, say, build errors or other unrelated bugs. It <i>is</i> true however that the type of build breakage potentially brought in by using git rebase will require you to do more bisect steps.

I use rebase because I often have long-running feature branches (maybe for a couple of weeks) and I want to keep up with changes on master. When I was new to git, I used to merge master into feature branches to achieve the same effect, but my pull requests were littered with commits already made to master.<p>Is there a better way to keep feature branches updated with changes on master?