Question

我正在早期进行一个正在进行的项目，每个开发人员有一个开发分支。因此，当实现某些功能时，我们创建一个PR（github）并将其合并到master。 PR后，我想继续与我的开发部门（同一部门）合作。

更新开发分支以匹配新的母版的正确方法是什么？以及在同一个分支机构完成PR后如何继续与我的开发部门一起工作？

我尝试过git rebase master站在我的开发部门。然后，我又得到了提交，因为它们已经从我的分支合并到主服务器中了（由于PR）。这使我的开发分支位于开发分支的起源之前。这样就可以在我的开发分支中进行合并。

有时，如果master分支中包含来自其他用户的其他一些提交，而我已经重新设置了基础，并希望创建一个新的PR。他们的承诺同样也出现在我的PR中。承诺他们已经合并到母版中。我已经尝试了很多事情，但现在我还是很困惑...

所以我认为正确的是以下工作流程：

<merge PR on github>
git checkout master 
git pull --rebase
git checkout my-dev-branch
git rebase master
<continue working in my-dev-branch>

但是，这里不正确，因为它会导致奇怪的合并/包含其他用户的提交等。

Answer 1

考虑这个反问：在钉子，平头或十字螺丝刀上使用正确的螺丝刀是什么？

更实际一点：git rebase所做的全部是 copy （一组）提交，然后在分支名称周围添加。也就是说，您在之前 git rebase：

...--F--G--H   <-- master
         \
          I--J--K   <-- feature

您运行git checkout feature; git rebase master的目标是：用一系列新的提交替换现有的提交I-J-K，这些提交是从I，J和{{1 }}，这样新的和改进的提交看起来像这样：

只要没有其他人正在使用I'-J'-K' <-- feature / ...--F--G--H <-- master \ I--J--K [abandoned] ，这是一个合理的事情。如果没有其他人，则可以随时安全进行操作。如果Bob和Carol拥有它们，但没有使用，并且您可以说服Bob和Carol切换到新的替换提交而完全不中断他们的工作，这仍然是安全，但现在您必须与另外两个人进行协调。

在某些情况下，即使其他人正在使用原始链并依赖原始链，也可能会这样做。在这里，他们必须知道如何处理他们的提交，因为现在他们在他们的中都有自己的附加提交 >存储库：

I-J-K

在将...--F--G--H <-- master \ I--J--K <-- feature \ L <-- bob替换为新的和改进的I-J-K之后，鲍勃将不得不用自己的新改进的I'-J'-K'替换自己的L。也许可以，但是最好在进行操作之前先与Bob确认。

合并的公关怎么样？

这是事情变得更加复杂的地方，尤其是当人们使用GitHub上的“ rebase and merge”或“ squash and merge”按钮时。

GitHub上的rebase-and-merge按钮使 GitHub 执行相同的替换技巧。也就是说，他们采用您的L'链并复制。 即使没有充分的理由，他们也会这样做。也就是说，假设您的提交看起来像这样：

I-J-K

通过使名称...--F--G--H <-- master \ I--J--K <-- feature在Git所谓的上下滑动，可以简单地在现有提交上添加这一系列提交快进操作：

master

但是GitHub不会这样做。当您（或某人）使用“重新合并”按钮时，他们将改为：

...--F--G--H
            \
             I--J--K   <-- feature, master

如果 you 在I'-J'-K' <-- feature / ...--F--G--H <-- master \ I--J--K [your PR - abandoned]之后有一个额外的提交L，则 you 现在与Bob的位置相同。您必须将K复制到L之后的新L'，而不必再次复制K'。

最简单的方法是根本没有I-J-K。只是放弃名为L的分支（例如，完全删除它），更新feature以便提交master，然后再次创建名称K' ，指向feature：

K'

没有人（包括您自己）会记住原始...--F--G--H--I'-J'-K' <-- feature, master链的哈希ID，它会“感觉像”您只是在最终提交{{1 }} {{1}之后：

I-J-K

“ squash and merge”按钮的工作方式与“ rebase and merge”按钮非常相似，除了GitHub不会一次复制一次提交，而GitHub会进行一次具有相同效果的提交就像他们复制了提交一样：

其中提交K'是合并...--F--G--H--I'-J'-K' <-- master \ L <-- feature的结果（就像通过...--F--G--H--IJK <-- master一样），然后进行普通的单亲提交（因此，就像通过{{1} }。和以前一样，如果您已经有IJK脱离了原始K，则必须放弃git merge，转而使用在新提交{之后的新副本git merge --squash {1}}。

如果你是鲍勃

一旦遇到我们最初归因于Bob的情况，您可以使用L相对方便地进行这种操作。 K选项可让您告诉Git：在更新后的L 之后放入副本，同时也让您告诉Git：不复制提交L'或IJK 之前的任何内容。如果没有git rebase --onto，则您的--onto会采用一个参数，这两个参数都是放置副本的位置和不复制的内容 ，则需要将它们分开。

在某些情况下，Git实际上可以为您解决这类问题。这就是master的{{1}}模式（自Git 2.0版以来可用（默认！））。不幸的是，这些情况都不适用于GitHub及其“ rebase-and-merge”或“ squash-and-merge”按钮。在其他情况下，其中一种在这里适用，Git可以仍然弄清楚这一点，但是，如果您看到很多关于重新设置基准的问题，则意味着Git <

PR

1 个答案:

合并的公关怎么样？

如果你是鲍勃