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' is not recognized as an internal or external command
  • Single-developer Git with Dropbox backups: seeking safe, simple configuration
  • git merge local with remote master using terminal
  • How can I move a tag on a git branch to a different commit?
  • E: Unable to locate package git - Ubuntu on EC2
  • JGit: How to pick and squash a region of commits from one branch to another
  • update: main reason for this – minimize number of potential conflicts (since committer(not release-manager) will resolve them)

  • Git ignore only files with the same name as folder
  • How to make git merge include summary of each commit?
  • Git telling me to pull, then commit, then pull?
  • git rebase resolve conflicts again and again?
  • Resuming git-svn clone
  • What are currently the problems with Git on Windows
  • 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.