<story><title>Protected branches and required status checks</title><url>https://github.com/blog/2051-protected-branches-and-required-status-checks</url><text></text></story><parent_chain></parent_chain><comment><author>ajross</author><text>This sounds like the wrong solution to me.  The problem isn&amp;#x27;t (or rather, is rarely[1]) that you&amp;#x27;ve &amp;quot;polluted&amp;quot; a public branch with bad code.  Bad code gets pushed into branches by perfectly legal commits all the time, and you fix it via software engineering and not administrative policy.&lt;p&gt;The real problem with the accidental force push is that it&amp;#x27;s lossy.  The OLD head, to which you would hope to revert when you realize your mistake, is suddenly invisible (and garbage-collectible!).&lt;p&gt;So I&amp;#x27;d much prefer to see github fix this with a &amp;quot;hard reflog&amp;quot; of the branch state on the server.  Track the head of each branch at each point in &amp;quot;monotonic server time&amp;quot; (with a tag or whatnot, or even outside the repository would be fine) such that you can always (1) detect force push events like this and (2) trivially revert them.&lt;p&gt;[1] Yeah, occasionally you might push your site keys, or some NDA-covered source code.  And in those situations you &lt;i&gt;want&lt;/i&gt; the reverting push to actually &amp;quot;forget&amp;quot; the code.  But that should be the rare exception and not the standard process.</text></comment>
<story><title>Protected branches and required status checks</title><url>https://github.com/blog/2051-protected-branches-and-required-status-checks</url><text></text></story><parent_chain></parent_chain><comment><author>tylerdiaz</author><text>I&amp;#x27;m a little surprised to see it took this long to release what some teams consider an essential feature. I worked at a company where force-pushing master (by-accident) would put the master branch in lock down while someone could fix its history, which is easily solved by this feature.</text></comment>