Git-在允许推送到分支之前需要合并来自master的提交

Question

We'd like to prevent lengthy merge conflicts between development branches by requiring these branches to pull/merge from the master branch before allowing a push to the development branch (if there are any changes to the master branch). Is this possible to enforce?

Answer 1

Yes, depending on how your central repository is hosted. If it's hosted at something like GitHub or GitLab.com, this will probably not be possible because these types of providers don't allow you to provide your own code to check pushes (you can configure some restrictions via their web interface but I don't think what you want is possible there).

For a self-hosted repository, you can do this in an update hook (see the documentation for hooks ). Here's an example that I haven't actually tested:

#!/bin/sh
if [ "$1" = "refs/heads/development" -a "$(git rev-list $3..master)" ]; then
  echo "ERROR: master is not merged into development, please try again" >&2
  exit 1
fi

This essentially checks that there's "nothing left" if you subtract the set of commits from the new state of development from the set of commits on master . If you have merged, development will have all of master 's commits so the result will be the empty set.

This is fairly simple but has a few minor drawbacks:

• If the same push also updates master , the check in this hook may not be aware of the new changes to master yet, so in that case you might get a false negative (unmerged changes but push goes through).
• If the last (and only) new thing that happened on master was a merge from development , the hook will give a false positive of sorts because master will have that merge commit while development won't. Of course we know that that's an immaterial difference between the two branches, but the simple set arithmetic in the hook doesn't understand these distinctions.