Hacker News Reader

I think this method seems to get more popular by day. IMHO, previously master was the branch you merge before the deploy process. But today this is reversed.

The main benefit is, other developers can rely on the master branch even more. They will know there will not be a revert on the master branch they just pulled one hour ago and already started coding on.

View on HN

A `git revert` creates a new commit. To a developer, a revert commit appearing on master has the same effect as a pull request (or ten) being merged into it. If the revert affects code you’re working on, you will need to resolve conflicts, just like you would need to if a merged PR affected the same code.

While what you're saying is true for all situations, the of the github flow is that to a developer relying on master, problematic code never made it in.

Agreed that any codes can be added/removed but those are 100% valid changes in github flow.

I thought this was what tests were for :)

Large software systems need all of tests, canaries, rollbacks.

Reply on news.ycombinator.com