HN user

im-poor

18 karma
Posts0
Comments8
View on HN
No posts found.

I think the difference between the two approaches comes down to the release cycle. For something like a backend that gets deployed multiple times a week, the most important thing is to get the backend working again once it breaks. Just as an example, for each minute that the Facebook ads backend is down, hundreds of thousands of dollars are lost. In this case, you really want to be able to remove changes entirely.

You still haven’t answered the question of why it’s valuable. You’re asking someone to do a lot of work by cleaning up their feature branch. What’s the benefit? The commits all get atomically added to master at the same time. Why would you want to revert to a state that master was never in? For instance, let’s say a feature is added and needs to be reverted. Personally, I prefer doing a single git revert <commit> and knowing that master is in a valid state.

What value do those commits really provide? In master, I want every commit to represent a change in state that I may want to revert to when rolling back or bisecting. I don’t ever want to go back in time mid-way through someone’s feature development. What use is that? If I’m curious about the specific history of that feature, I’ll go to the branch it came from.