3 ms·

Show HN: GitHub doesn't support fast-forward commits. This fixes it

5 points by sebmellen 3y ago

sebmellen 3y ago
In case anyone is having issues with the lack of -ff merge options in GitHub's web UI, this Protected GitHub fast-forward commit action with Mergefreeze may help. This is not an ideal solution, and it will cost your organization an additional $40/month for the Mergefreeze subscription, but it works well. We spent a lot of time figuring it out. Mergefreeze, combined with the action, prevents you from accidentally merging via the default web UI options by blocking them using a branch protection rule. The fast-forward action blocks all commits to your desired branch that don't use the action. When run by adding a /fast-forward comment to your PR, the action temporarily suspends the required Mergefreeze branch protection rule, merges the commit to your desired branch through the CLI, and then adds back the branch protection rule. This avoids any mistaken merge/rebase commits to the protected branch, and it works just as fast as merging using the traditional web UI options. Hope this helps someone!
stephenr 3y ago
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.

5 points by sebmellen 3y ago

In case anyone is having issues with the lack of -ff merge options in GitHub's web UI, this Protected GitHub fast-forward commit action with Mergefreeze may help. This is not an ideal solution, and it will cost your organization an additional $40/month for the Mergefreeze subscription, but it works well. We spent a lot of time figuring it out. Mergefreeze, combined with the action, prevents you from accidentally merging via the default web UI options by blocking them using a branch protection rule. The fast-forward action blocks all commits to your desired branch that don't use the action. When run by adding a /fast-forward comment to your PR, the action temporarily suspends the required Mergefreeze branch protection rule, merges the commit to your desired branch through the CLI, and then adds back the branch protection rule. This avoids any mistaken merge/rebase commits to the protected branch, and it works just as fast as merging using the traditional web UI options. Hope this helps someone!

stephenr 3y ago

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.