我已经和另一个开发人员在一个项目中使用Git好几个月了。我在SVN方面有几年的经验，所以我想我给这种关系带来了很多包袱。
我听说Git在分支和合并方面非常出色，但到目前为止，我还没有看到这一点。当然，分支非常简单，但当我尝试合并时，一切都变得一团糟。现在，我已经习惯了SVN的版本，但对我来说，我只是把一个低于标准的版本系统换成了另一个。
我的合作伙伴告诉我，我的问题源于我想要合并的愿望，并且在许多情况下我应该使用rebase而不是合并。例如，这是他制定的工作流程:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature
本质上，创建一个特性分支，总是从主分支到分支，并从分支合并回主分支。需要注意的是，分支始终保持在本地。
这是我开始的工作流程
clone remote repository
create my_new_feature branch on remote repository
git checkout -b --track my_new_feature origin/my_new_feature
..work, commit, push to origin/my_new_feature
git merge master (to get some changes that my partner added)
..work, commit, push to origin/my_new_feature
git merge master
..finish my_new_feature, push to origin/my_new_feature
git checkout master
git merge my_new_feature
delete remote branch
delete local branch
有两个本质的区别(我认为):我总是使用merge而不是rebase，并且我将我的特性分支(以及我的特性分支提交)推到远程存储库。
我使用远程分支的理由是，我希望在工作时备份我的工作。我们的存储库是自动备份的，如果出现问题可以恢复。我的笔记本电脑没有，或者说没有那么彻底。因此，我讨厌我的笔记本电脑上的代码没有镜像到其他地方。
我选择合并而不是rebase的原因是合并似乎是标准的，而rebase似乎是一个高级特性。我的直觉是，我试图做的不是一个先进的设置，所以rebase应该是不必要的。我甚至仔细阅读了关于Git的新Pragmatic Programming书，其中涉及了大量的merge，而很少提到rebase。
不管怎样，我在最近的分支上遵循我的工作流，当我试图将它合并回master时，一切都糟透了。与本不重要的事情有很多冲突。这些冲突对我来说毫无意义。我花了一天的时间来整理所有的事情，最终在强制推送到远程的主人，因为我的本地主人已经解决了所有的冲突，但远程的主人仍然不高兴。
对于这样的事情，“正确的”工作流是什么?Git应该让分支和合并变得超级简单，但我没有看到这一点。
更新2011-04-15
这似乎是一个非常受欢迎的问题，所以我想我应该更新一下我第一次问这个问题以来两年的经验。
原来的工作流程是正确的，至少在我们的例子中是这样。换句话说，这就是我们所做的，而且很有效:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge my_new_feature
事实上，我们的工作流程有点不同，因为我们倾向于做压缩合并而不是原始合并。(注:这是有争议的，见下文。)这允许我们将整个特性分支转换为在master上的单个提交。然后我们删除我们的特征分支。这允许我们在master上逻辑地构造提交，即使它们在我们的分支上有点乱。这就是我们所做的:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge --squash my_new_feature
git commit -m "added my_new_feature"
git branch -D my_new_feature
壁球合并争议-正如一些评论者指出的，壁球合并将丢弃你的特性分支的所有历史。顾名思义，它将所有提交压缩成一个单一的提交。对于小功能来说，这是有意义的，因为它将其压缩成一个包。对于较大的特性，这可能不是一个好主意，特别是如果您的个人提交已经是原子的。这实际上取决于个人喜好。
Github和Bitbucket(其他的?)Pull Requests——如果你想知道merge/rebase与Pull Requests有什么关系，我建议你按照上面所有的步骤，直到你准备好合并回master。而不是用git手动合并，你只是接受PR。注意，这不会做挤压合并(至少默认情况下不会)，但非挤压，非快进是Pull Request社区接受的合并约定(据我所知)。具体来说，它是这样工作的:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git push # May need to force push
...submit PR, wait for a review, make any changes requested for the PR
git rebase master
git push # Will probably need to force push (-f), due to previous rebases from master
...accept the PR, most likely also deleting the feature branch in the process
git checkout master
git branch -d my_new_feature
git remote prune origin
我已经爱上了Git，再也不想回到SVN。如果你在挣扎，坚持下去，最终你会看到隧道尽头的光明。
