<story><title>Don&apos;t use Git rebase</title><url>https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1</url></story><parent_chain><item><author>fulafel</author><text>What&amp;#x27;s even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing.&lt;p&gt;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.&lt;p&gt;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.&lt;p&gt;edit: towards the middle of the article, the author also opines
&amp;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.&amp;quot;</text></item></parent_chain><comment><author>Vinnl</author><text>There&amp;#x27;s no such thing as &amp;quot;real&amp;quot; history - you don&amp;#x27;t commit every line of code you add or remove, or even every character. Rather, you choose some points in time to commit.&lt;p&gt;For me, those are often arbitrary - I can&amp;#x27;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.&lt;p&gt;Before I merge my branch back into master, though, I want my commit history to be useful. &amp;quot;This is the point where I went home or was disturbed that day&amp;quot; is not useful to future developers. &amp;quot;This is the work I did on this individual feature and everything that&amp;#x27;s needed to run it and to have the tests succeed is in this commit, and this was the reasoning behind what I did&amp;quot;, however, is.&lt;p&gt;In other words, I rebase to divide my codebase into non-arbitrary units of code, not based on chronology, but on what is useful together.</text></comment>
<story><title>Don&apos;t use Git rebase</title><url>https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1</url></story><parent_chain><item><author>fulafel</author><text>What&amp;#x27;s even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing.&lt;p&gt;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.&lt;p&gt;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.&lt;p&gt;edit: towards the middle of the article, the author also opines
&amp;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.&amp;quot;</text></item></parent_chain><comment><author>pandemi</author><text>The main use case for rebase for me is to add automatic rebases on pull to the git config.&lt;p&gt;Normally if you pull from the remote and have local commits not in the remote, you&amp;#x27;ll have an &amp;quot;extra&amp;quot; merge. Automatic rebase on pull takes care of this, to avoid those useless merges.</text></comment>