How to successfully keep master and development branches in sync? GIT

Question

I like to do development on my development branch then merge into master when I am ready to push to production. As long as I don't commit anything to the master branch all goes smoothly.

However, I have come across situations where I have committed something to the master branch that conflicts with something that was changed on the development branch. When I merge the development branch into the master I have to resolve the conflict. No big deal, but then in order to make sure the development branch has everything in the master branch (making sure development is up-to-date) I merge the master branch in and end up having to resolve the conflicts again.

I've heard that rebasing is generally bad, especially for things you are pushing out publicly.

Is there a better way to manage this type of setup?

Answer 1

Periodically merge from the master to your development branch, and resolve any conflicts then. (If you're doing that regularly, conflicts will generally be very minor.)

By the time the merge back to master happens, development shouldn't conflict at all.

Answer 2

I think you might just have a few misconceptions here that are affecting you more than anything being technically wrong.

First, you should generally not commit directly to the master branch. From the way you described your situation, I'm not sure if that's happening or not, but if it is, try not to do that.

If you discover that something cannot cleanly be merged into master, you should not try to fix the problem on master itself. Instead, you should fix the problem on the feature branch. Once you have fixed the problem there, you can then merge into master cleanly.

As far as rebase goes, it's perfectly fine to use rebase until you push to a remote repository. Once you have pushed something to a remote repo, you don't want to rebase, as then you're messing up history for someone else, and git can't really resolve that for you. So don't fear rebase, just know when to use it and when not to use it.

One way you might be able to use rebasing here (again, assuming you have not pushed the branch in question remotely) to help with your problem is to take the feature branch that cannot cleanly be merged into master and rebase it onto master. This will then force you to resolve the problem on that branch. Once it has been resolved, the merge into master should be trivial (unless master has been altered again in the meantime) and you can cleanly merge into master.

There are many tutorials available for git out there, and they'll have some nice code examples to help too. Here's one of the more 'classic' ones, I believe the workflow described here works well. http://nvie.com/posts/a-successful-git-branching-model/

Please note I'm not endorsing the bash script set named 'git flow' that attempts to semi-automate the workflow there (those scripts didn't work very well for us when we tried them) but the workflow itself described there works well.

Answer 3

The way I would do it is the other way round:

1. merge master to dev
2. merge dev to master just after that

resolving all conflicts while merging.

Although git is superb when it comes to merging and handling branches, I don't think there is a quick way around resolving conflicts other than manual, tedious work using 3-way diff/merge tools.

Also, it helps to do what @cHao said in his answer below - merge often, merge small, and you will barely have large conflict merge situations.

Answer 4

from what i can tell, develop is where all the new stuff happens. so, if that's the case, branch off of develop (feature branch). work on that branch. when you're done, just merge develop into your feature branch to make sure it's up to date. then, checkout the develop branch and merge your feature branch into it. as the folks on your team continue to add features to the develop branch, at some point the manager is gonna be like okay, we're releasing , so at that point you'll merge master into develop (just incase someone made a rogue commit on master) and then checkout master and merge develop into it.

hopefully no one commits directly to develop or to master. those two should only get merged to. also, i hope you have tests for while you're developing a feature and for after a merge.

as far as rebase is concerned, yes, they say don't do it after you've shared your branch. so in this case you wouldn't do it on develop branch because it's shared.

Answer 5

I do

git checkout master
git reset --hard dev

So master becomes exactly dev. Just don't forget to rebase dev if you want to submit hotfix on master.