Great question. I’m not the one you asked, but I can answer.
Yes, merge commits, though they get useful work done, cause challenges later. If you’re using GitHub you can actually disable the ‘merge commit’ pattern in the repository settings, under ‘branch protections’, and you’ll have a much nicer time moving code between branches in the future.
Since you’re working on patterns, if you’re using GitHub, here’s my best tip - it’s related but will also cause some other nice outcomes.
If you’re using GitHub, to get a much better branching experience, you can turn on branch protections on ‘main’ and specifically turn on ‘require linear history’. This will let GitHub know that you prioritize the quality of the history in ‘main’ over that of all other branches.
Related: If your team keeps a ‘develop’ branch, you’ll need to get rid of it at the same time as making this change. Using a ‘develop’ branch is not compatible with this setup. Code that used to merge to ‘develop’ should now merge to ‘main’ and git tags should be what indicates code is ready for production.
With these settings GitHub will nudge your team towards squashing and rebasing when merging, and operations to pull other people’s code into your branch will get dramatically easier. (Edit: You’ll start to see the keyword ‘fast-forward’ a lot more often, which is great.)
If you’re not using GitHub, you can still look for tools and setups to “require linear history” to get the same benefits.
Great question. I’m not the one you asked, but I can answer.
Yes, merge commits, though they get useful work done, cause challenges later. If you’re using GitHub you can actually disable the ‘merge commit’ pattern in the repository settings, under ‘branch protections’, and you’ll have a much nicer time moving code between branches in the future.
Since you’re working on patterns, if you’re using GitHub, here’s my best tip - it’s related but will also cause some other nice outcomes.
If you’re using GitHub, to get a much better branching experience, you can turn on branch protections on ‘main’ and specifically turn on ‘require linear history’. This will let GitHub know that you prioritize the quality of the history in ‘main’ over that of all other branches.
Related: If your team keeps a ‘develop’ branch, you’ll need to get rid of it at the same time as making this change. Using a ‘develop’ branch is not compatible with this setup. Code that used to merge to ‘develop’ should now merge to ‘main’ and git tags should be what indicates code is ready for production.
With these settings GitHub will nudge your team towards squashing and rebasing when merging, and operations to pull other people’s code into your branch will get dramatically easier. (Edit: You’ll start to see the keyword ‘fast-forward’ a lot more often, which is great.)
If you’re not using GitHub, you can still look for tools and setups to “require linear history” to get the same benefits.
This Is The Way.