Is there an alternative to a “push” hook?

Question

Bitbucket, Github and other services tend to have a \"push\" hook, so that when you push code to the repository, the service can hit a url (possible on a production server),

Answer 1

The push event of a GitHub webhook allows for the repository server (GitHub) to contact repository clients (your servers in the cloud)

But if that doesn't work, you would have two approaches:

• have one dedicated repo client (one dedicated server of yours) which would be contacted by this GitHub webhook, and would know which servers on the cloud are available and need to be contacted.
• or switch to a pull approach where a server on the cloud periodically does a git pull, followed by a git push to a bare repo (still on the same cloud server): a post-receive hook on that bare repo can be triggered if the git push pushed anything at all (As I mentioned in the comments of "How to execute a command right after a fetch or pull command in git?").

Answer 2

Bitbucket, Github and other services tend to have a "push" hook

Actually, a Git repo hosting server will have another option with Git 2.10 (Q3 2016): push options.

See commit 3ac8703, commit f6a4e61, commit c714e45, commit 77a9745 (14 Jul 2016) by Stefan Beller (stefanbeller).
^{(Merged by Junio C Hamano -- gitster -- in commit cf27c79, 03 Aug 2016)}

That feature was proposed in this thread:

Allow a user to pass information along a push to the pre/post-receive hook on the remote.

When using a remote that is more than just a plain Git host (e.g. Gerrit, Git{hub/lab}, etc) this may become more obvious: The (server backend specific) push options can instruct the server to:

• open a pull request
• send out emails asking for review
• (un)trigger continuous integration
• set priority for continuous integration (i.e. bots pushing may ask to be treated with lower priority compared to humans)
• ...

Most of these actions can be done on the client side as well, but in these remote-centric workflows it is easier to do that on the remote, which is why we need to transport the information there.

More concrete examples:

• When you want a change in Gerrit to be submitted to refs/heads/master, you push instead to a magic branch refs/for/master and Gerrit will create a change for you (similar to a pull request).
  Instead we could imagine that you push to a magical refs/heads/master with a push option "create-change".
• When pushing to Gerrit you can already attach some of this information by adding a '%' followed by the parameter to the ref, i.e. when interacting with Gerrit it is possible to do things like1:

git push origin HEAD:refs/for/master%draft%topic=example%cc=jon.doe@xxxxxxxxxxx

This is not appealing to our users as it looks like hacks upon hacks to make it work.

It would read better if it was spelled as:

git push origin HEAD:refs/for/master \
  --push-option draft \
  --push-option topic=example \
  --push-option cc=jon.doe@xxxxxxxxxxx

(with a short form that is even easier to type, but this is is more intuitive already)