5 ms·

I liked that too. But I prefer to hide merge commits using: git shortlog -sn --no-merges

tabbott 8y ago
Zulip has a rebase-based development workflow and doesn't use merge commits because in my experience, it produces a much more readable commit history (which is really important for understanding historical changes). We've been very happy with this approach. Some relevant reading on our version control approach for those who might be interested: * https://zulip.readthedocs.io/en/latest/git/overview.html https://zulip.readthedocs.io/en/latest/git/overview.html * https://zulip.readthedocs.io/en/latest/contributing/version-control.html https://zulip.readthedocs.io/en/latest/contributing/version-...
- jtchang 8y ago
  Doesn't using rebase generally mean you have to rebase on top of master and thus with your local branch you may need to git push --force ?
  - tabbott 8y ago
    Yes. The default GitHub-recommended workflow of having contributors do `git pull` to integrate their changes an easily result in a confusing spaghetti monster history even if the contributor only has 1-2 commits that don't merge conflict with anything. For this reason, most major open source projects use that part of the workflow (asking their contributors to rebase their PRs on top of master and never use `git pull --merge`), even if they plan to merge the commits into master via a merge commit. (The Git documentation is very aggressive in discouraging force-pushing of commits, but that advice is intended for a public repository, like the main zulip.git repository, that others might pull from. Obviously, we don't force-push to zulip.git, but if you're using Git right, you should be force-pushing to your fork when you fix a typo in one of your commits.)
  - 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.

Zulip has a rebase-based development workflow and doesn't use merge commits because in my experience, it produces a much more readable commit history (which is really important for understanding historical changes). We've been very happy with this approach. Some relevant reading on our version control approach for those who might be interested: * https://zulip.readthedocs.io/en/latest/git/overview.html https://zulip.readthedocs.io/en/latest/git/overview.html * https://zulip.readthedocs.io/en/latest/contributing/version-control.html https://zulip.readthedocs.io/en/latest/contributing/version-...

jtchang 8y ago
Doesn't using rebase generally mean you have to rebase on top of master and thus with your local branch you may need to git push --force ?
- tabbott 8y ago
  Yes. The default GitHub-recommended workflow of having contributors do `git pull` to integrate their changes an easily result in a confusing spaghetti monster history even if the contributor only has 1-2 commits that don't merge conflict with anything. For this reason, most major open source projects use that part of the workflow (asking their contributors to rebase their PRs on top of master and never use `git pull --merge`), even if they plan to merge the commits into master via a merge commit. (The Git documentation is very aggressive in discouraging force-pushing of commits, but that advice is intended for a public repository, like the main zulip.git repository, that others might pull from. Obviously, we don't force-push to zulip.git, but if you're using Git right, you should be force-pushing to your fork when you fix a typo in one of your commits.)
- 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.