0

I saw this mistake happens more than once in our team. Let's say we have two branches: Dev and Prod. User switches to prod branch, commits a change, then, instead of doing 'git pull origin prod' to fetch the last changes on prod, he does by mistake 'git pull origin dev'. As a result, it merges dev branch into prod, which is not cool.

What I tried to do is to ask the developers not to use 'git pull origin branchname', instead, just use 'git pull'. (the local branch should be tracked to the remote for this..). Usually, this approach works well for us, yet, accidents might happen and I believe there is a way of avoiding it somehow.

Improve this question

2 Answers 2

Reset to default
1

A hacky way to make this would be to define some bash function called git that wraps the execution of the git binary. If the second parameter is "pull" you ignore the fourth parameter (the branch name), or compare it to your current branch name, maybe.

Another approach would be to play with git hooks to ensure this rules, but you have to be able to define the rules accurately. As a pull is just a fetch + merge, and sometimes you'll want to merge develop into master (when deploying a new release), it would be hard to define.

It's hard to expect technology to solve human behavior's issues. Accustom your team to avoid using that extra parameters, it will pay off - maybe using the wrapper function to warn them each time they try to put the branch name on the command. Talk with them - that's the only way to solve this things.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Thanks, I'll take it into consideration if I won't have other option. I would prefer a solution which not involve changes in all user environments. It seems, as you said, there is no hook for pool, and the hook of merge won't help me since I couldn't know whether the merge came from pull or not.
0

You can only make this less likely, not impossible (someone can always deliberately mess things up :-) ).

What you can do, if you use the typical "push changes back via ssh" model, is set up the bare repo (from which people fetch/pull and to which they push) with a pre-receive hook, that checks for such merges and disallows them. Of course some approved person(s) probably should be allowed, but you can add this to the hook as well.

This is nontrivial to get right and a quick search didn't turn up one I liked.

Improve this answer

4 Comments

yup.. that's why I asked here. Thanks. It'll be problematic to disable the merge option to some users, since all of them merge from prod to dev. Maybe if it's possible to configure that merge from dev to prod will be done only by a list of users, that might solve the problem. However, I thought it should be simpler, if there is a hook which works when doing 'git pull', I can try to find out what is the current branch and what is the parameter, then decide whether allow or deny it.
I spent some (perhaps too much :-) ) time on such a script, but it's still poorly tested at best. I put up a copy here.
Thank you very much. Can you please give a short description what this script does?
There's a long comment at the front on "how to use it" (with "git config" settings). But you will have to do some testing, by putting it on a dummy/test repo for instance, and experimenting with "good" vs "bad" pushes.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.