Git post-receive - how to check if pushed branch is merged with master
Asked Answered
B

4

2

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)

Bugleweed answered 4/1, 2010 at 6:58 Comment(0)
M
2

If git cherry new-branch master has any output, then someone didn't rebase before pushing.

Misprision answered 4/1, 2010 at 18:23 Comment(0)
L
1

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.

Loudermilk answered 4/1, 2010 at 7:38 Comment(1)
Yes, that's what I'm trying to accomplish - BUT the main problem is that developers forget to pull master and rebase - so I want them recive notification that they forget to do thisBugleweed
M
1

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.

Mallissa answered 4/1, 2010 at 8:22 Comment(0)
A
0

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.

Antipope answered 4/1, 2010 at 7:22 Comment(1)
Exactly - what I want is - minimize number of conflictsBugleweed

© 2022 - 2024 — McMap. All rights reserved.