4 ms·

How is this different from the built in branch protection rule? - [ ] Require linear history Prevent merge commits from being pushed to matching branches.

sebmellen 3y ago
Quite shockingly, GitHub's "linear history" option is anything but. Even when using the "Rebase and Merge" option (which is supposedly linear history), you will find that in a typical dev -> staging -> prod workflow, when you merge into higher environments, GitHub creates different commits, resulting in staging or prod being some number of commits ahead of the branch it is supposed to be downstream of. This breaks a lot of development workflows. From a discussion on the GitHub community board: > I had absolutely no idea that this was the case for years and I'm actually quite surprised that Github is doing something non-'standard' here. I didn't actually believe it when I first read about it and had to try it myself. Sure enough, Github is performing full replays of history instead of doing fast-forwards, resulting in different commits. My own personal workflow isn't particular impacted by this but thinking back to professional settings this is starting to paint a picture as to why rebases were so inexplicably problematic when people used the Github UI to do them as opposed to on the command line. [0] [0]: https://github.com/orgs/community/discussions/4618#discussioncomment-5930868 https://github.com/orgs/community/discussions/4618#discussio... This thread explains well: https://github.com/orgs/community/discussions/4618 https://github.com/orgs/community/discussions/4618.
- stephenr 3y ago
  Wow. So not only do they not support it, they make it seem like they do. The fact that I haven't hit this is probably a sign of how often I use the web UI for merging.
  - sebmellen 3y ago
    Yep! It’s deceptive. Worse yet, there’s no native way to disable these merge types, so if you want to restrict a branch to only use -ff merges you need to hack together something with branch protection rules, otherwise it’s very easy to accidentally merge in a non linear commit. That’s what this action does.

sebmellen 3y ago

Quite shockingly, GitHub's "linear history" option is anything but. Even when using the "Rebase and Merge" option (which is supposedly linear history), you will find that in a typical dev -> staging -> prod workflow, when you merge into higher environments, GitHub creates different commits, resulting in staging or prod being some number of commits ahead of the branch it is supposed to be downstream of. This breaks a lot of development workflows. From a discussion on the GitHub community board: > I had absolutely no idea that this was the case for years and I'm actually quite surprised that Github is doing something non-'standard' here. I didn't actually believe it when I first read about it and had to try it myself. Sure enough, Github is performing full replays of history instead of doing fast-forwards, resulting in different commits. My own personal workflow isn't particular impacted by this but thinking back to professional settings this is starting to paint a picture as to why rebases were so inexplicably problematic when people used the Github UI to do them as opposed to on the command line. [0] [0]: https://github.com/orgs/community/discussions/4618#discussioncomment-5930868 https://github.com/orgs/community/discussions/4618#discussio... This thread explains well: https://github.com/orgs/community/discussions/4618 https://github.com/orgs/community/discussions/4618.

stephenr 3y ago
Wow. So not only do they not support it, they make it seem like they do. The fact that I haven't hit this is probably a sign of how often I use the web UI for merging.
- sebmellen 3y ago
  Yep! It’s deceptive. Worse yet, there’s no native way to disable these merge types, so if you want to restrict a branch to only use -ff merges you need to hack together something with branch protection rules, otherwise it’s very easy to accidentally merge in a non linear commit. That’s what this action does.