我已经和另一个开发者在一个项目上使用Git几个月了。我有数年的SVN经验，所以我想我对这种关系带来了很多包袱。
我听说Git在分支和合并方面非常出色，但到目前为止，我并没有看到它的优势。当然，分支非常简单，但是当我尝试合并时，一切都变得一团糟。现在，我从SVN中习惯了这种情况，但我觉得我只是把一个次优的版本控制系统换成了另一个。
我的合作伙伴告诉我，我的问题源于我想随意合并，而且在许多情况下应该使用rebase而不是merge。例如，他制定了以下工作流程：
基本上，创建一个功能分支，始终从主分支到分支进行变基，然后从分支合并回主分支。重要的是要注意分支始终保留在本地。
这是我开始使用的工作流程。
我认为有两个关键的区别：我总是使用合并而不是变基，并且将我的特性分支（以及我的特性分支提交）推送到远程仓库。
我选择远程分支的原因是我希望在工作时备份我的工作。我们的存储库会自动备份，并且如果出现问题，可以进行恢复。我的笔记本电脑没有这样彻底的备份。因此，我不喜欢在我的笔记本电脑上有未在其他地方镜像的代码。
我选择合并而不是变基的原因是合并似乎是标准操作，而变基似乎是高级功能。我的直觉告诉我，我尝试做的事情不是高级设置，因此不需要变基。我甚至研究了 Git 的新编程书籍，它详细介绍了合并，几乎没有提到变基。
无论如何，我最近在遵循我的工作流程时遇到了问题，当我尝试将其合并回主分支时，一切都变得混乱。有大量与不应该有影响的事情发生冲突。这些冲突对我来说毫无意义。我花了一天时间解决所有问题，并最终强制将其推送到远程主分支，因为我的本地主分支已经解决了所有冲突，但远程主分支仍然不满意。
在这种情况下，“正确”的工作流程是什么？Git 应该使分支和合并变得超级简单，但我却看不到它。
实际上，我们的工作流略有不同，因为我们倾向于使用“压缩合并”而不是原始合并。（注意：这是有争议的，请参见下文。）这使我们能够将整个特性分支转换为主分支上的单个提交。然后我们删除我们的特性分支。即使在我们的分支上有些混乱，这也使我们能够在主分支上逻辑地构建我们的提交。所以，这就是我们做的：
我听说Git在分支和合并方面非常出色，但到目前为止，我并没有看到它的优势。当然，分支非常简单，但是当我尝试合并时，一切都变得一团糟。现在，我从SVN中习惯了这种情况，但我觉得我只是把一个次优的版本控制系统换成了另一个。
我的合作伙伴告诉我，我的问题源于我想随意合并，而且在许多情况下应该使用rebase而不是merge。例如，他制定了以下工作流程：
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
我认为有两个关键的区别：我总是使用合并而不是变基，并且将我的特性分支（以及我的特性分支提交）推送到远程仓库。
我选择远程分支的原因是我希望在工作时备份我的工作。我们的存储库会自动备份，并且如果出现问题，可以进行恢复。我的笔记本电脑没有这样彻底的备份。因此，我不喜欢在我的笔记本电脑上有未在其他地方镜像的代码。
我选择合并而不是变基的原因是合并似乎是标准操作，而变基似乎是高级功能。我的直觉告诉我，我尝试做的事情不是高级设置，因此不需要变基。我甚至研究了 Git 的新编程书籍，它详细介绍了合并，几乎没有提到变基。
无论如何，我最近在遵循我的工作流程时遇到了问题，当我尝试将其合并回主分支时，一切都变得混乱。有大量与不应该有影响的事情发生冲突。这些冲突对我来说毫无意义。我花了一天时间解决所有问题，并最终强制将其推送到远程主分支，因为我的本地主分支已经解决了所有冲突，但远程主分支仍然不满意。
在这种情况下，“正确”的工作流程是什么？Git 应该使分支和合并变得超级简单，但我却看不到它。
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
实际上，我们的工作流略有不同，因为我们倾向于使用“压缩合并”而不是原始合并。（注意：这是有争议的，请参见下文。）这使我们能够将整个特性分支转换为主分支上的单个提交。然后我们删除我们的特性分支。即使在我们的分支上有些混乱，这也使我们能够在主分支上逻辑地构建我们的提交。所以，这就是我们做的：
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
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。如果你正在挣扎，请坚持下去，最终你会看到隧道尽头的光明。
rebase有很大帮助。 - Jon Phenow