tags:

views:

62

answers:

2

I am using git and I have two branches: production and master. At this time production is 9 months old and a lot of changes have gone into master branch.

I am using capistrano and so I need to push all the changes to production branch so that I could deploy. However when I merge I get tons of merge conflicts. I don't care about merge issues because I want my production branch to be overridden by master branch. Is there a way to do it.

If not I was thinking of creating a branch of production called production_old. Then delete everything in production branch and then merge from master.

I am using github.

+1  A: 

Maybe the ours merge strategy is what you are looking for.

ours This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches.

more ... http://www.kernel.org/pub/software/scm/git/docs/git-merge.html

The MYYN
Actually, `ours` would be used if Roger were trying to merge production to master since `ours` considers the branch being merged to be obsolete. In Roger's case, he wants the checked out branch to be considered obsolete in favor of the branch being merged.
jamessan
A: 

Caveat: I don't have experience using github. That having been said...

I don't think you really want a merge here. If I understand correctly, you have a branch that reflects what's deployed (production), and you have a branch that includes the deployed content as well as newer changes (master), but now you're ready to promote the changes in master to be the new production content.

In this case, I think your last suggestion is close to what you want to do, though you shouldn't need to play with deleting the content inside the existing production branch. I would

  1. Tag the current production branch so that you don't lose track of it.
  2. Move the production branch to point to the head of master.

I believe you can do step #2 by running git branch -f production master, which should create a new production branch using master as a starting point. Because production already exists, you need the -f flag to force its creation. This should also be equivalent to running git checkout production, then git reset --hard master to force the head of the branch to match master.

Again, I would be sure to tag the head of your original production branch before doing anything, both for posterity as well as a safety net in case this doesn't work right the first time.

MikeSep