Git post-receive – how to check if pushed branch is merged with master
In our team we are usually pushing all tasks into separate branches, and after that release-manager review those branches and merge them into ‘master’ branch
Sometimes team-members forget to merge their branches with master branch(before pushing) – so what I’m trying to do is – output a message “Please merge with master” after user push – I assume I need to check something on post-receive hook on remote.. is there some examples?.. or what I should basically do ?
update: main reason for this – minimize number of potential conflicts (since committer(not release-manager) will resolve them)
4 Solutions collect form web for “Git post-receive – how to check if pushed branch is merged with master”
git cherry new-branch master has any output, then someone didn’t rebase before pushing.
I suppose by “merge with master”, you actually mean rebase on top of master.
Every developer should:
- pull master
- rebase its branch on top of master before pushing it
in order for the release-manager to have a fast-forward only merge after reviewing the branch.
If any kind of conflict appears, the same release-manager should notify the developer, asking him to (again) pull master and do a rebase.
That way, only the developer is in charge of solving conflicts, not the release-manager.
See rebase vs. merge
For an automatic process, I would go with a central update hook, which would try to perform a merge to master, and check if “fast-forward” is part of the output of the command. If not, the hook will fail with a
I have no example of such a script at the moment.
There isn’t really a good way of doing this. There are quite a few complications, the most obvious one is that your rebase-from-master / push-to-master operation is not atomic. I.e. someone might push something in-between. I would rather suggest you have a look e.g. Gitorious which makes the release manager’s work a lot easier. He can easily see what the commit includes and can accept/reject the commits easily.
But you might find git-wtf helpful. It shows how to compare the local repository with the remote one if you still insist on trying an automated solution.
You really don’t want to keep criss-crossing merges. Either the topic branches should be merged into master, or the branches should remain separate, being merged from master.
Perhaps what you’re looking for is that a branch before being pushed gets rebased on master, so that the number of potential conflicts is minimized, since the contributor has already resolved most of them.