Question

Our team has recently migrated to git.

We have production web application server with some small changes to code

• ultra hot hotfixes specific to this installaton
• some debugging statements for those bugs that can’t reproduced in our testing enviroment

I think, we can’t commit those in server repo.

When we had svn update either merged changed file or not merged. Now

 git stash; git pull; git stash pop

does the trick for me

How can I automatically detect those cases when git stash pop will cause conflicts

making production working copy broken?

I want send mail to resolve these cases manually

before they occur like be advised, pull cancelled (conflicts)

Answer 1

I would not want to bear the risk of having a merge conflict occur on a production server. This sounds all wrong to me.

From your post, I can infer that you have issues in production that you can’t reproduce in testing/staging. To help detect those, you added additional instrumentation to your application. This is a common approach, although you should really try to get failures reproduced in Q&A (usually it’s worth the initial hit in terms of long-term benefits).

The next thing I’d infer is that you’re directly manipulating code on a production server. You should NEVER EVER do this. You’re already using git which gives you a great flexibility of how you can manage things, there are smarter solutions to your problem.
Here’s what I’d to:

1. Get those changes from the server (create a patch or something)
2. Put those changes on to a local branch in your dev repo.
3. Whenever you change something rebase that local branch on top of your masters HEAD. Resolve conflicts locally.
4. Since you’ve mocked with history, you need to force a push into the production repository, see How do I push amended commit to the remote Git repository? for details.

It can also be debated whether you wouldn’t want to “productize” the additional logging you added, making it part of your non-functional requirements.