This could have saved my morning...
Protected branches and required status checks
11–20 of 49 posts
Re: Protected branches and required status checks
#12I'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.
I don't think github was created with a shared repository model in mind. If you are forking which is the implied model this feature is relatively pointless because they offer you "pull only" from forks.
Re: Protected branches and required status checks
#13Gitlab has protected branches feature for quite sometime. I was wondering when Github is going to implement it. Finally!!!
Protected branches have been a feature of Bitbucket also for a long time.
Re: Protected branches and required status checks
#14As a mercurial user, how easy IS it to accidentally force-push in Git? You have to really go out of your way to do it in mercurial, and I haven't found any reasons to do so.
> how easy IS it to accidentally force-push in Git?
It's easy to accidentally force-push to the wrong branch. If you're on the wrong branch (e.g. you think you're on your personal dev branch and want to update it after a rebase but you're actually on the mainline) `git push -f` will ruthlessly clobber the remote.
Re: Protected branches and required status checks
#15A good fix is to religiously use `--force-with-least` rather than `--force`. Sadly because Git I know no way to make force-with-lease the default and make —force less convenient (outside of a `git force` alias, which isn't going to disable `push —force` so you'll have to train it into your muscle memory) force-with-lease checks that the actual remote head and the local one match before pushing, which prevents overwri…
I think the point is to protect a branch at the origin so that the mistake of using the wrong options doesn't cause damage. Training everyone on a team to do the right thing is good, but everyone is prone to mistakes (myself included, even after using git for years).
Re: Protected branches and required status checks
#16As a mercurial user, how easy IS it to accidentally force-push in Git? You have to really go out of your way to do it in mercurial, and I haven't found any reasons to do so.
Someone much wider than me once told me: if I ever felt the need to use the force flag as part of a command (hg or not), odds are I'm trying to do something I shouldn't be doing. As it turns out, I haven't used that flag since, because whenever I thought I needed it, it turned out I was going about something the wrong way.
That being said, like you, I use hg, haven't used git very much.
Re: Protected branches and required status checks
#17This sounds like the wrong solution to me. The problem isn't (or rather, is rarely[1]) that you've "polluted" 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.
The real problem with the accidental force push is that it's lossy. The OLD head, to which you would hope to revert when you realize your mistake, is suddenly invisible (and garbage-collectible!).
So I'd much prefer to see github fix this with a "hard reflog" of the branch state on the server. Track the head of each branch at each point in "monotonic server time" (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.
[1] Yeah, occasionally you might push your site keys, or some NDA-covered source code. And in those situations you want the reverting push to actually "forget" the code. But that should be the rare exception and not the standard process.
Re: Protected branches and required status checks
#18Does the "required status check" thing apply to `git push`, or just to the merge button on the website?
If it applies to `git push`, how do you trigger a status check to run on your actual merge/rebase as made in your local client, which will almost certainly differ in SHA1 and may differ in content from the merge made in the PR?
Re: Protected branches and required status checks
#19I'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.
Github still offer pretty weak configuration of permissions. e.g. the Dolphin team decided against migrating to Github due to the poor flexibility in permissions. https://dolphin-emu.org/blog/2015/09/01/dolphin-progress-rep... You can't have users who have the ability to triage issues without also giving them write access to the repository. https://help.github.com/articles/permission-levels-for-an-or...
Re: Protected branches and required status checks
#20Does the "required status check" thing apply to `git push`, or just to the merge button on the website? If it applies to `git push`, how do you trigger a status check to run on your actual merge/rebase as made in your local client, which will almost certainly differ in SHA1 and may differ in content from the merge made in the PR?
[deleted]