Git工作流程和rebase与合并问题

Question

我和其他开发人员一起在一个项目上使用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上阅读了新的实用编程书，它们涵盖了广泛的合并，几乎没有提到rebase。

无论如何，我在最近的一个分支上关注我的工作流程，当我试图将它合并回主人时，一切都进入了地狱。对于应该不重要的事情存在大量冲突。冲突对我来说毫无意义。我花了一天的时间来解决所有事情，并最终被强制推向远程主人，因为我的当地主人解决了所有冲突，但是远程主人仍然不高兴。

这样的事情的“正确”工作流程是什么？ 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上逻辑地构造我们的提交，即使它们在我们的分支上有点乱。所以，这就是我们所做的：

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。您只需接受PR，而不是手动与git合并。请注意，这不会进行压缩合并（至少不会默认），但非压缩，非快进是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。如果你正在努力，只要坚持下去，最终你会看到隧道尽头的光线。

Answer 1

另一答案

Answer 2

另一答案

Answer 3

另一答案

Answer 4

另一答案

Answer 5

另一答案

Answer 6

另一答案

Answer 7

另一答案

Answer 8

变基与合并git rebase git merge

你真的懂git rebase吗？

为啥 git rebase 的合并冲突通常比合并少？

合并代码还在用 git merge？我们都用 git rebase

git rebase 不使用分支

git svn rebase 错过/丢失提交（在 rebase --continue 由于合并冲突）？

Git工作流程和rebase与合并问题

TL;DR

Rebase workflow is not better for conflict resolution!

原因＃1：解决冲突一次，而不是每次提交一次

Real scenario

原因＃2：使用rebase，没有撤消！

Take the hell out of conflict resolution: use diff3

Alternate: Resolve by manually applying the branch's changes