At the moment git is doing my head in, I cannot come up with the best solution for the following.
There are two branches, one called master and one called mobiledevicesupport. I want to keep mobiledevicesupport as a continuous branch that will be merged/synced with the master branch whenever mobiledevicesupport is stable. This would merge changes from mobiledevicesupport into master but also bring all the changes from master into mobiledevicesupport so that branch can continue to be worked on and the features improved or amended. This needs to work with a central repository and multiple developers.
Please an example of similar workflows other people use or just tell me if this idea is stupid and I should consider other options. At the moment the workflow seems sound, but I just don't know how I can make git work this way.
Thanks, all help much appreciated.
Update 1: If I was to merge master into mobiledevicesupport and mobiledevice support into master, do I get replicated commits across both branches. Or is git smart enough to work out that I have pulled the latest changes from branch A into branch B and add merge commit C to branch B. And I have pulled the latest changes from branch B into branch A and add merge commit D to branch A?
I was going to post an image but I don't have enough reputation for it, so I guess the following illustration will have to do. Two branches continuously running with merges going both directions often. The key thing I am not sure about is how git will play out the commits and will it fill either branch with the commits from the other branch on merges or will it stay clean. I have used rebase before but it seems to end the branch and put all the commits into the master, or I did it wrong. Thanks for the help so far.
master
A--B--C-----H--I--J--M--N
\ / \
mobile \ / \
D--E--F--G--------K--L
This question is related to
git
Yeah I agree with your approach. To merge mobiledevicesupport into master you can use
git checkout master
git pull origin master //Get all latest commits of master branch
git merge mobiledevicesupport
Similarly you can also merge master in mobiledevicesupport.
Q. If cross merging is an issue or not.
A. Well it depends upon the commits made in mobile* branch and master branch from the last time they were synced. Take this example: After last sync, following commits happen to these branches
Master branch: A -> B -> C [where A,B,C are commits]
Mobile branch: D -> E
Now, suppose commit B made some changes to file a.txt and commit D also made some changes to a.txt. Let us have a look at the impact of each operation of merging now,
git checkout master //Switches to master branch
git pull // Get the commits you don't have. May be your fellow workers have made them.
git merge mobiledevicesupport // It will try to add D and E in master branch.
Now, there are two types of merging possible
Git will first try to make FF merge and if it finds any conflicts are not resolvable by git. It fails the merge and asks you to merge. In this case, a new commit will occur which is responsible for resolving conflicts in a.txt.
So Bottom line is Cross merging is not an issue and ultimately you have to do it and that is what syncing means. Make sure you dirty your hands in merging branches before doing anything in production.
You are thinking in the right direction. Merge master with mobiledevicesupport continuously and merge mobiledevicesupport with master when mobiledevicesupport is stable. Each developer will have his own branch and can merge to and from either on master or mobiledevicesupport depending on their role.
Run the following commands:
$ git checkout mobiledevice
$ git pull origin master
This would merge all the latest commits to your branch. If the merge results in some conflicts, you'll need to fix them.
I don't know if this is the best practice but works for me.
The accepted answer via git merge will get the job done but leaves a messy commit hisotry, correct way should be 'rebase' via the following steps(assuming you want to keep your feature branch in sycn with develop before you do the final push before PR).
1 git fetch from your feature branch (make sure the feature branch you are working on is update to date)
2 git rebase origin/develop
3 if any conflict shall arise, resolve them one by one
4 use git rebase --continue once all conflicts are dealt with
5 git push --force
Whenever you want to get the changes from master into your work branch, do a git rebase <remote>/master. If there are any conflicts. resolve them.
When your work branch is ready, rebase again and then do git push <remote> HEAD:master. This will update the master branch on remote (central repo).
concept47's approach is the right way to do it, but I'd advise to merge with the --no-ff option in order to keep your commit history clear.
git checkout develop
git pull --rebase
git checkout NewFeatureBranch
git merge --no-ff master
Source: Stackoverflow.com