4 ms·

You rebase your feature/topic branches on top of master and then merge the feature/topic branch back onto master, enabling a fast-forward merge.

by rekwah 8y ago

austinjp 8y ago
Is this a common workflow? Googling suggests almost religious feelings about this.
- rekwah 8y ago
  Anecdotally, I feel it's less common than merge commits. There are plenty of places driven by the "Merge Pull Request" button in GitHub and that's the default functionality. In personal projects or those with fewer developers, I prefer rebase + FF merge for a clean history. I don't really feel the need to see the merge commit in the master branch history.
- woodrowbarlow 8y ago
  it comes down to whether you want your version history to reflect the true version of development's history (merge), or a simpler, doctored version of history which reflects the final deliverable (rebase). advocates of the latter, myself included, argue that it eliminates noise and tells all the story that needs to be told -- and that the original history can be preserved by not deleting the feature branches. others argue that changing your parent commit is dangerous and occlusive. i think the core of it comes down to the UX for "git log", which attempts to display history linearly when in fact it absolutely is not. ask yourself: what is the _contents_ of a merge commit? if you know git well, you know that the merge commit contains everything from the feature branch... and that the feature commits you see when you run "git log" on master are actually not on master at all. so the rebase strategy makes master truly linear to match the tools and reduce cognitive load. however, the rebase strategy does introduce new possibilities of tool-driven bugs and requires more rigor. this article has a good run-down of the risks: https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1 https://medium.com/@fredrikmorken/why-you-should-stop-using-... the classic example of a rebase pitfall is: a) you branch from master, b) on your feature branch, develop a feature utilizing dependency x, c) meanwhile, on master, another developer removes dependency x, d) you rebase back on top of master -- there are no conflicts, and things look good, but the build is completely broken.
- tedmiston 8y ago
  Yes, it's common for open source projects. I've used a rebase workflow for feature branches in Apache projects and others. It takes a little more work for each contributor but leaves history on master very clean.
jedbrown 8y ago
Warning: If you don't also squash the entire topic branch, then you will sometimes break git bisect with this workflow.

You rebase your feature/topic branches on top of master and then merge the feature/topic branch back onto master, enabling a fast-forward merge.

by rekwah 8y ago

You rebase your feature/topic branches on top of master and then merge the feature/topic branch back onto master, enabling a fast-forward merge.

austinjp 8y ago

Is this a common workflow? Googling suggests almost religious feelings about this.

rekwah 8y ago
Anecdotally, I feel it's less common than merge commits. There are plenty of places driven by the "Merge Pull Request" button in GitHub and that's the default functionality. In personal projects or those with fewer developers, I prefer rebase + FF merge for a clean history. I don't really feel the need to see the merge commit in the master branch history.
woodrowbarlow 8y ago
it comes down to whether you want your version history to reflect the true version of development's history (merge), or a simpler, doctored version of history which reflects the final deliverable (rebase). advocates of the latter, myself included, argue that it eliminates noise and tells all the story that needs to be told -- and that the original history can be preserved by not deleting the feature branches. others argue that changing your parent commit is dangerous and occlusive. i think the core of it comes down to the UX for "git log", which attempts to display history linearly when in fact it absolutely is not. ask yourself: what is the _contents_ of a merge commit? if you know git well, you know that the merge commit contains everything from the feature branch... and that the feature commits you see when you run "git log" on master are actually not on master at all. so the rebase strategy makes master truly linear to match the tools and reduce cognitive load. however, the rebase strategy does introduce new possibilities of tool-driven bugs and requires more rigor. this article has a good run-down of the risks: https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1 https://medium.com/@fredrikmorken/why-you-should-stop-using-... the classic example of a rebase pitfall is: a) you branch from master, b) on your feature branch, develop a feature utilizing dependency x, c) meanwhile, on master, another developer removes dependency x, d) you rebase back on top of master -- there are no conflicts, and things look good, but the build is completely broken.
tedmiston 8y ago
Yes, it's common for open source projects. I've used a rebase workflow for feature branches in Apache projects and others. It takes a little more work for each contributor but leaves history on master very clean.

jedbrown 8y ago

Warning: If you don't also squash the entire topic branch, then you will sometimes break git bisect with this workflow.