Tell HN: Linear history is broken when using GitHub PRs
Have you ever noticed how GitHub has no fast-forward pull request merges?
Did you know it's impossible to use GitHub PRs without rebasing your dev branch on main after every merged PR?
Please, if anybody knows somebody at GitHub that can help address this glaring limitation (15 years into GitHub's life), please help. My linear history people and I are desperate.
2 comments
[ 3.6 ms ] story [ 13.9 ms ] threadBut also, you should be fine as long as you use merge commits. The thing that will mess up your history is if you let it rebase commits, since then you'll end up with diverged history.
https://docs.github.com/en/pull-requests/collaborating-with-...
Let's say you're working on dev, you add two commits, and now you want to merge these to main.
Most people don't know that GitHub has no PR merge method that simply allows you to copy those two commits onto main.
It's literally impossible for you to use GitHub PRs to simply have dev become main.
Here's why:
If you use a merge commit, it will create a merge commit ("The pull request is merged using the --no-ff option.") So dev isn't becoming main; main is becoming something new.
If you use squash and merge, it will rewrite your two commits into a single commit. But you wanted two commits or you would have already done one commit in dev. Again, dev isn't becoming main; main is becoming something new.
If you use rebase and merge, it should then copy your two commits onto main, but in fact, it rewrites them with new commit hashes, it's not a copy. Then, you need to rebase dev back onto main because main is now something new.
More detail: https://github.com/orgs/community/discussions/4618#discussio...