我有我的master分支和一个develop分支用于处理一些更改。我需要将更改从master合并到develop,但最终将从develop合并到master。我有两个不同的工作流程:
master
develop
git pull origin master
git merge master
哪一种方法是最好的,为什么?
这类事情的最佳方法可能是git rebase。它允许你从master中将更改拉到你的开发分支中,但将所有的开发工作“放在”master的内容之上(稍后在提交日志中)。当您的新工作完成后,合并回主系统就非常简单了。
git rebase
这个工作流程最适合我:
git checkout -b develop
...做一些改变…
...通知主版已更新…
做出改变来发展…
git checkout master git pull
...将这些变化带回开发中……
git checkout develop git rebase master
...做更多的改变…
让他们发展…
...将它们合并到主…
git checkout master git pull git merge develop
如果你不与任何人共享开发分支,那么我就会在master每次更新时重新设置它,这样你就不会在你的历史中有合并提交,一旦你将开发合并回master。这种情况下的工作流程如下:
> git clone git://<remote_repo_path>/ <local_repo> > cd <local_repo> > git checkout -b develop ....do a lot of work on develop ....do all the commits > git pull origin master > git rebase master develop
以上步骤将确保您的开发分支始终处于来自主分支的最新更改之上。一旦你完成了开发分支,并将其重新基于master上的最新更改,你可以将其合并回来:
> git checkout -b master > git merge develop > git branch -d develop
小心变基。如果你与任何人共享你的开发分支,rebase会把事情搞得一团糟。Rebase只对你自己的本地分支有好处。
经验法则,如果你已经将分支推到原点,就不要使用rebase。相反,使用merge。
我的经验法则是:
rebase用于具有相同的名称的分支,否则为merge。
rebase
merge
相同名字的例子是master, origin/master和otherRemote/master。
origin/master
otherRemote/master
如果develop只存在于本地存储库中,并且它总是基于最近的origin/master提交,你应该称它为master,并直接在那里工作。它简化了你的生活,并如实呈现事物:你直接在master分支上开发。
如果develop是共享的,它不应该基于master重做,而只是与--no-ff合并回它。你在develop上开发。master和develop有不同的名字,因为我们希望它们是不同的东西,并且保持分离。不要让它们与rebase相同。
--no-ff
我更喜欢使用git pull origin <branch_name>到我想合并到的分支。 我实际上从未使用过git merge <branch_name>
git pull origin <branch_name>
git merge <branch_name>
git pull
git fetch
git merge
2个命令vs 1个命令;让工作快速进行变得简单。
PS:如果你不确定会发生什么,最好使用“分解”命令;)