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 ?

  • Git with a central repository
  • Rename Git branch folder
  • how to embed DVCS revision information when building without it
  • How do I get IntelliJ to see my remote git branches
  • How to restore the project if I have only .git folder?
  • ansible - iterate all hosts and retrieve data from results
  • update: main reason for this – minimize number of potential conflicts (since committer(not release-manager) will resolve them)

  • How to deal with a git local folder within another?
  • Meaning of leading slash in `.gitignore` file
  • Show branches that do not contain commit
  • Pushing to git repository cloned from KIE Workbench repository
  • Git - fatal: bad default revision 'HEAD' & notice: HEAD points to unborn branch (master)
  • Show message as well as diff with git stash show
  • 4 Solutions collect form web for “Git post-receive – how to check if pushed branch is merged with master”

    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.

    Git Baby is a git and github fan, let's start git clone.