Don’t use GitHub’s “Rebase and Merge” workflow (yet)
In September last year, GitHub introduced a couple of new behaviors to its “Merge” button as alternatives to the standard of creating a new merge commit every time. Namely, “Squash and Merge” and “Rebase and Merge.”
“Rebase and Merge” is appealing if you already lean toward git rebase
over git merge
for whatever reason (won’t go into that holy war here). However, it has a bug that I’ve replicated by following these steps:
- I created a PR with two commits in it: https://github.com/jcfrancisco/rebase-revert-bug-example/pull/2
- I merged that PR into master using the “Rebase” method.
- I clicked the Revert button on that PR, creating this revert PR: https://github.com/jcfrancisco/rebase-revert-bug-example/pull/3
- Note that the revert PR only undos the second out of the two commits in the original PR.
In other words, the Revert button doesn’t actually revert the PR— it only reverts the final commit in that PR. This could be a deal-breaker for products or libraries that rely on the Revert button to undo a PR’s worth of work instantly.
So don’t use “Rebase and Merge” yet. GitHub is working on a fix — when I reached out to their support team, they said they have an “issue open with the team” about it but that there’s “no specific ETA on when a fix will happen.” They also said they’d email me when it is fixed, and I’ll update this post when that happens.
UPDATE: Looks like GitHub pushed out a fix within a few hours of my emailing support, and the Revert button now works as intended.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!