This is a very practical question, but all the answers above are not practical.
git checkout master git pull origin master git merge test git push origin master
This approach has two issues:
It's unsafe, because we don't know if there are any conflicts between test branch and master branch.
It would "squeeze" all test commits into one merge commit on master; that is to say on master branch, we can't see the all change logs of test branch.
So, when we suspect there would some conflicts, we can have following git operations:
git checkout test git pull git checkout master git pull git merge --no-ff --no-commit test
commit, avoid a fast-forward commit by
If conflict is encountered, we can run
git status to check details about the conflicts and try to solve
Once we solve the conflicts, or if there is no conflict, we
git commit -m 'merge test branch' git push
But this way will lose the changes history logged in test branch, and it would make master branch to be hard for other developers to understand the history of the project.
So the best method is we have to use
rebase instead of
merge (suppose, when in this time, we have solved the branch conflicts).
Following is one simple sample, for advanced operations, please refer to http://git-scm.com/book/en/v2/Git-Branching-Rebasing
git checkout master git pull git checkout test git pull git rebase -i master git checkout master git merge test
Yep, when you have uppers done, all the Test branch's commits will be moved onto the head of Master branch. The major benefit of rebasing is that you get a linear and much cleaner project history.
The only thing you need to avoid is: never use
rebase on public branch, like master branch.
Never do operations like the following:
git checkout master git rebase -i test
Details for https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing