Protected branches and required status checks

> Does the "required status check" thing apply to `git push`, or just to the merge button on the website?

It applies to all ways of updating git: push, the web UI, merging, and the API.

> 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?

If they differ in SHA1 but not content, things will work fine. A protected branch cannot be updated to a git tree that has not been tested.

If your PR differs in content, clicking the 'update branch' button on a PR will make the merge commit and your PR's content the same, so a new CI run will apply to the correct content.

You'll get no argument from me there.

As a Git user, it seems Very Hard to accidentally force push: you need to add a command line parameter, and I was simply taught "Don't Do That". I've certainly never done it.

e.g.:

  # yes!
  git push origin my-feature-branch
  git push origin master

  # no!
  git push --force origin master

nsfyn55 makes a good point about protection from others, though. Maintaining my own fork, and using pull requests to the central repo, seems to help avoid others clobbering master, but that seems to be more of a reflection of my organization's Git workflow.

If your team treats Git the way we used to use Mercurial, where each developer will merge their changes into master and then push it, you're going to be in a WORLD of hurt. (It's likely we were doing it wrong there, too. I didn't really grok distributed source control until we moved to Git.)

If you use the Github Flow [0], the merging is done in the UI of your Github (or Gitlab/etc) instance, rather than directly with `git`. (I believe Atlassian's stash has a similar but slightly different recommended workflow.) The keys for us are:

  - One team repo is the "official" repo. (e.g., UI/foo-widget)
  - Each dev forks the repo, and pushes their branches on that fork 
    (e.g. gknoy/foo-widget:gk-feature)
  - Pull Requests are made from the dev's repo __to the official one__ 
    (e.g. from gknoy/foo-widget's gk-feature branch 
          to UI/foo-widget's master branch)

Some teams instead opt to have each dev make branches on the same (official) repo. I prefer the extra safety net of maintaining my own fork. If I were to mistakenly commit something (or merge something, or rebase something) incorrectly, and totally fubar my repo's master branch, and then push that up to my origin before noticing it, I can recover it easily (rename branches, checkout the commit that should be the head, re-push). Worst case, I can delete my fork and re-fork it. ;) If I were to do that on a repo that I have shared access to, I'd have much more anxiety.

Incidentally, I've made exactly that mistake (merged or committed something onto my local master, and then pushed it to my origin) TWICE, and caught when others have when doing code reviews. The first time, I panicked and deleted/re-created my forked repo. The second time, I fixed it by juggling branches, and it was substantially easier. (Slower: it took me ~20 minutes I think?) In neither case did my mistakes affect anyone else, though, since the repo I messed up was my own.)

This is, of course, based heavily on Github's suggested practices, since we use Github Enterprise at work. Were I using Stash or GitLab, there would likely be some changes, but I think the team workflow really benefits when you dive all-in on Git's distributed nature.

0: https://guides.github.com/introduction/flow/

Thanks! That's a very sensible model. I suppose it means that the status-check API can't be used to check that the history of a branch is up to some standards, like commit messages following a style or all commits in history passing some check, but that's fine. (It is a bit at odds with the documentation of the status-check API, which implies that it's about refs, not trees.)

> 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!).

I prefer how Mercurial behaves in this matter. A push can not destroy old heads, and the old (dangling) heads still show up in the log by default (you can filter them out with an option, if you don't want to see them).

So if someone pushes a new head by accident, anyone can still see what is going on, and fix the situation either by a merge, or reverting back to the old head.

(The downside is, if everyone really knows what they are doing and never make mistakes, git's way of deleting old heads with just a force push is easier, than needing to specifically access the repo on a server if you want to delete some heads.)