4 ms·

The most important bit in my opinion: > When merging fixes and features into master, we avoid merge commits and use rebases and fast-forward as much as possibl

The most important bit in my opinion: > When merging fixes and features into master, we avoid merge commits and use rebases and fast-forward as much as possible. Rebasing feature branches, and avoiding non-ff merges has been the best change I've ever made to my workflow. Makes it very easy to keep a clean, readable history that is actually useful when doing code archeology months later. Resolving conflicts is far easier than via merging too.

jgraham 6y ago
If you have tooling to support it, rebase-and-ff-merge is perhaps an even better workflow. In this model every commit on the main branch has a first parent that's the previous merge, and a second parent that's a linear set of the commits that were landed together, with the parent of the first commit being the previous state of master. This has the following advantages: * It's clear which states master has actually been in, without having to resort to squashing each merge into a single commit. This means that you know which commits actually passed CI and are therefore good rebase targets. People often claim that when merging multiple commits each commit should individually pass CI, but that's almost impossible to achieve in practice. * Development can split single features into multiple commits for easier review and understanding later. This can be particuarly important if the changes depend on each other, but different people need to review different parts of the overall change. That's another thing that most tooling is really bad at. * The history is basically linear. The merge commits are all empty, and there is one linear history for all the states of master (the first parent of each merge commit) and one linear history for all the individual commits (the second parent of each merge commit and only parent of each non-merge commit). Of course this approach isn't well supported by mainstream tooling (e.g. GitHub) and probably requires a custom bot to do all the rebase-and-merge operations. It is pretty well supported by git itself, however.
- ufo 6y ago
  Does anyone know how to make this "cactus" workflow work better on github? We use it in our organization and between us we know to always manually rebase before merging. However, when we receive an external PR from someone else it's a pain. It's also easy to accidentally forget to rebase before merging.
  - tele_ski 6y ago
    I always go into each new repo I create and turn off the ability to merge and require commits to be up to date with master, I think this might get what you want?
    - ufo 6y ago
      Do you know can I enforce that a PR must be up to date with master before it can be merged? I don't remember seeing that option in the branch protection settings.
      - tele_ski 6y ago
        "Require branches to be up to date before merging" is a check box under branch protection rules, I always turn it it. It's under the required status checks section.
        ufo 6y ago
        Thanks! Turns out that this setting is hidden unless you first check the "Require status checks" option.
        tele_ski 6y ago
        Oh good to know! I forgot it's hidden until that section is enabled. Does feel like a feature that should be top level, OSIT!
  - divbzero 6y ago
    You can allow rebase merging [1] while disabling other PR options, and require linear commit history [2] if desired. [1]: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuring-commit-rebasing-for-pull-requests https://docs.github.com/en/free-pro-team@latest/github/admin... [2]: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/requiring-a-linear-commit-history https://docs.github.com/en/free-pro-team@latest/github/admin...
gwenzek 6y ago
The issue is that Git sucks at rebasing. Every conflict you fix when rebasing will need to be fixed again next time you rebase.
- mklein994 6y ago
  Enter git rerere: https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere This will "REuse REcorded REsolutions" of conflicted merges. Once enabled, it will record how a merge conflict was resolved, and replay it back the next time it encounters it. Saves a lot of time in cases where you already solved the merge once before. https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere
  - not_kurt_godel 6y ago
    rerere gives me nightmares. Much prefer some delicate merging footwork if at all possible.
- SassyGrapefruit 6y ago
  I can confidently say I've never encountered this. To diagnose I'd have to see what exactly you are doing, but I suspect you have issues with the way you organize your work. Git is not a magic wand. Making effective use of a hammer starts with the boards and nails.
- ricardobeat 6y ago
  True, it's one of the downsides. You have to also be in the 'short-lived branches' camp for it to work well - which you should!
yarcob 6y ago
The problem with rebase is that you must resolve conflicts for every commit. This can take a lot of effort versus a single merge at the end. You end up doing a lot of conflict resolution when rebasing, increasing the chances that you make an error. And if you do make an error during conflict resolution, there will be no record of it because you've rewritten history. We stopped most rebases for this reason, and just do normal merges. Conflict resolution is easier, and if we do make a mistake, it's at least documented in the history, and it's easier to fix.
GuB-42 6y ago
Maybe that's because I came from Mercurial but I dislike rebase workflows. You can rebase as long as it is in your repository and you didn't publish anything, you are free to do whatever you want on your PC. But as soon as it becomes public, it is history, and you don't change history. Git is decentralized, and works kind of like a blockchain. With Bitcoin, the foundation is that everyone share the same history, no one should be able to rewrite transactions. I expect the same behavior from decentralized version control systems. And if you make a mess, too bad, it is here to stay. It is ugly, but it is what really happened. If it really is a huge mess, call the admin so that he can fix the thing, notify everyone that the history has changed, and have your name added to the hall of shame. But that's a personal opinion. I know some people prefer a clean (but fake) history over a messy (but true) history. Continuous integration tools tend to like clean histories for instance. You can even have both system coexist. A messy/true history branch where developers work and a whitewashed version running in parallel for integrators.

jgraham 6y ago

If you have tooling to support it, rebase-and-ff-merge is perhaps an even better workflow. In this model every commit on the main branch has a first parent that's the previous merge, and a second parent that's a linear set of the commits that were landed together, with the parent of the first commit being the previous state of master. This has the following advantages: * It's clear which states master has actually been in, without having to resort to squashing each merge into a single commit. This means that you know which commits actually passed CI and are therefore good rebase targets. People often claim that when merging multiple commits each commit should individually pass CI, but that's almost impossible to achieve in practice. * Development can split single features into multiple commits for easier review and understanding later. This can be particuarly important if the changes depend on each other, but different people need to review different parts of the overall change. That's another thing that most tooling is really bad at. * The history is basically linear. The merge commits are all empty, and there is one linear history for all the states of master (the first parent of each merge commit) and one linear history for all the individual commits (the second parent of each merge commit and only parent of each non-merge commit). Of course this approach isn't well supported by mainstream tooling (e.g. GitHub) and probably requires a custom bot to do all the rebase-and-merge operations. It is pretty well supported by git itself, however.

ufo 6y ago
Does anyone know how to make this "cactus" workflow work better on github? We use it in our organization and between us we know to always manually rebase before merging. However, when we receive an external PR from someone else it's a pain. It's also easy to accidentally forget to rebase before merging.
- tele_ski 6y ago
  I always go into each new repo I create and turn off the ability to merge and require commits to be up to date with master, I think this might get what you want?
  - ufo 6y ago
    Do you know can I enforce that a PR must be up to date with master before it can be merged? I don't remember seeing that option in the branch protection settings.
    - tele_ski 6y ago
      "Require branches to be up to date before merging" is a check box under branch protection rules, I always turn it it. It's under the required status checks section.
      - ufo 6y ago
        Thanks! Turns out that this setting is hidden unless you first check the "Require status checks" option.
        tele_ski 6y ago
        Oh good to know! I forgot it's hidden until that section is enabled. Does feel like a feature that should be top level, OSIT!
- divbzero 6y ago
  You can allow rebase merging [1] while disabling other PR options, and require linear commit history [2] if desired. [1]: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuring-commit-rebasing-for-pull-requests https://docs.github.com/en/free-pro-team@latest/github/admin... [2]: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/requiring-a-linear-commit-history https://docs.github.com/en/free-pro-team@latest/github/admin...

gwenzek 6y ago

The issue is that Git sucks at rebasing. Every conflict you fix when rebasing will need to be fixed again next time you rebase.

mklein994 6y ago
Enter git rerere: https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere This will "REuse REcorded REsolutions" of conflicted merges. Once enabled, it will record how a merge conflict was resolved, and replay it back the next time it encounters it. Saves a lot of time in cases where you already solved the merge once before. https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere
- not_kurt_godel 6y ago
  rerere gives me nightmares. Much prefer some delicate merging footwork if at all possible.
SassyGrapefruit 6y ago
I can confidently say I've never encountered this. To diagnose I'd have to see what exactly you are doing, but I suspect you have issues with the way you organize your work. Git is not a magic wand. Making effective use of a hammer starts with the boards and nails.
ricardobeat 6y ago
True, it's one of the downsides. You have to also be in the 'short-lived branches' camp for it to work well - which you should!

yarcob 6y ago

The problem with rebase is that you must resolve conflicts for every commit. This can take a lot of effort versus a single merge at the end. You end up doing a lot of conflict resolution when rebasing, increasing the chances that you make an error. And if you do make an error during conflict resolution, there will be no record of it because you've rewritten history. We stopped most rebases for this reason, and just do normal merges. Conflict resolution is easier, and if we do make a mistake, it's at least documented in the history, and it's easier to fix.

GuB-42 6y ago

Maybe that's because I came from Mercurial but I dislike rebase workflows. You can rebase as long as it is in your repository and you didn't publish anything, you are free to do whatever you want on your PC. But as soon as it becomes public, it is history, and you don't change history. Git is decentralized, and works kind of like a blockchain. With Bitcoin, the foundation is that everyone share the same history, no one should be able to rewrite transactions. I expect the same behavior from decentralized version control systems. And if you make a mess, too bad, it is here to stay. It is ugly, but it is what really happened. If it really is a huge mess, call the admin so that he can fix the thing, notify everyone that the history has changed, and have your name added to the hall of shame. But that's a personal opinion. I know some people prefer a clean (but fake) history over a messy (but true) history. Continuous integration tools tend to like clean histories for instance. You can even have both system coexist. A messy/true history branch where developers work and a whitewashed version running in parallel for integrators.