Best (and safest) way to merge a git branch into master
A new branch from master is created, we call it test .
There are several developers who either commit to master or create other branches and later merge into master .
Let's say work on test is taking several days and you want to continuously keep test updated with commits inside master .
I would do git pull origin master from test .
Question 1: Is this the right approach? Other developers could have easily worked on same files as I have worked btw.
My work on test is done and I am ready to merge it back to master . Here are the two ways I can think of:
A:
git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test
B:
git checkout test
git pull origin master
git checkout master
git merge test
I am not using --rebase because from my understanding, rebase will get the changes from master and stack mine on top of that hence it could overwrite changes other people made.
Question 2: Which one of these two methods is right? What is the difference there?
The goal in all of this is to keep my test branch updated with the things happening in master and later I could merge them back into master hoping to keep the timeline as linear as possible.
How I would do this
git checkout master
git pull origin master
git merge test
git push origin master
If I have a local branch from a remote one, I don't feel comfortable with merging other branches than this one with the remote. Also I would not push my changes, until I'm happy with what I want to push and also I wouldn't push things at all, that are only for me and my local repository. In your description it seems, that test is only for you? So no reason to publish it.
git always tries to respect yours and others changes, and so will --rebase . I don't think I can explain it appropriately, so have a look at the Git book - Rebasing or git-ready: Intro into rebasing for a little description. It's a quite cool feature
This is a very practical question, but all the answers above are not practical.
Like
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
Test merge before commit , avoid a fast-forward commit by --no-ff ,
If conflict is encountered, we can run git status to check details about the conflicts and try to solve
git status
Once we solve the conflicts, or if there is no conflict, we commit and push them
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.
like following operation:
git checkout master
git rebase -i test
never do these operations.
Details for https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing
appendix:
Neither a rebase nor a merge should overwrite anyone's changes (unless you choose to do so when resolving a conflict).
The usual approach while developing is
git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier
When you're ready to merge back into master,
git checkout master
git log ..test # if you're curious
git merge test
git push
If you're worried about breaking something on the merge, git merge --abort is there for you.
Using push and then pull as a means of merging is silly. I'm also not sure why you're pushing test to origin.
链接地址: http://www.djcxy.com/p/1364.html上一篇: 如何在Vim中用换行符替换一个字符？