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 ?

up开发者_StackOverflowdate: main reason for this - minimize number of potential conflicts (since committer(not release-manager) will resolve them)

If 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 git send-email.
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.