在共享特性分支上使用git重基安全吗？

Question

我的一位同事从我们的主要分支feature/dotnet6创建了一个特性分支developing，用于将我们的一些.NET框架项目迁移到.NET 6。

他的特性分支已经有一段时间了，它是19 commits ahead和218 commits behind developing。

几天前，我开始将一个API .NET框架项目迁移到.NET 6。

为此，我从同事的特性分支feature/dotnet6-web-api中创建了自己的特性分支feature/dotnet6，因为我需要他已经完成的一些工作。

在我的特性分支feature/dotnet6-web-api上做了一些工作之后，现在是46 commits ahead和218 commits behind developing了。

一旦我的分支工作完成，我将创建一个PR，将我的特性分支feature/dotnet6-web-api合并到我的同事特性分支feature/dotnet6中。

此时，我们将有一个特性分支feature/dotnet6，它将包含所有的.NET 6迁移工作，然后可以进行PR并合并回我们的主要分支developing中。

我想更新我同事的特性分支feature/dotnet6和我的特性分支feature/dotnet6-web-api，其中包含了自特性分支创建以来一直致力于我们的主要分支developing的工作。

我想我应该检查一下我同事的特性分支feature/dotnet6，然后重新建立在developing上。例如：

git checkout developing
git pull

git checkout feature/dotnet6
git rebase developing
git push --force

一旦完成，我将签出我的特性分支feature/dotnet6-web-api，并重新基于我同事的特性分支feature/dotnet6。例如：

git checkout feature/dotnet6
git pull

git checkout feature/dotnet6-web-api
git rebase feature/dotnet6
git push --force

我担心的是：

通过将我同事的特性分支(

1. )重新定位会对他产生影响吗?在将我同事的特性分支feature/dotnet6的最终版本合并到我们的主要分支( developing )中时，这会不会造成问题，因为从重基提交将有不同的SHA到“相同”提交在我们的主分支
2. 中已经存在。

我会更好地将我们的主要分支developing合并到我们的两个特性分支中，还是重新定位，以及它可能导致的潜在问题？

Answer 1

TLDR:坚持合并

作为一般规则，您应该永远不要重基共享分支。要更直接地回答你的问题：

1. 是的，重新定位会影响到他。从本质上说，重基的工作方式是在您要重新定位的分支上创建一个临时分支，将您的分支的头重置为原始/开发(或您告诉它的任何承诺)，然后从临时分支中选择您的提交，这样它们就在上面。樱桃-选择更改提交哈希，因为它创建了一个新的提交。这意味着当你的同事去拉的时候，他会有不匹配的提交散列，这会给git带来相当大的混乱。如果他有自己没有推动的本地更改，这可能会导致问题，因为well.

• One可能的方法是执行重基而不是合并的git pull --rebase。它还试图查看代码中的差异，以便识别具有相同更改但散列不同的提交。我以前曾使用它与我的同事共享分支，而且它通常都能工作。尽管如此，对于像你同事这样长寿的分支机构，我不会冒it.

1. Potentially.的险如果您进行了重基，通常不会影响origin/developing上的提交散列，除非您在此之前指定了一个基。如果发生这种情况，git可能会将它们显示为冲突，因为它不知道是与developing中的更改还是您的更改相匹配。

对你和你的同事来说，做以下事情要安全得多：

git checkout feature/dotnet6
git pull origin developing   # This will merge the latest developing into your branch without the need to checkout your local copy of developing and pull.
git push
git checkout feature/dotnet6-web-api
git pull origin developing
git push

Git在合并方面非常出色，这也将允许你们两人稍后合并到一起。

如果你真的想要一个线性的历史，你们两个可以在合并代码之后，但是在提高PR之前，做一个重基。这样，历史是线性的，合并是扁平的，在发展过程中你不会踩到对方的脚趾。然而，这种方法的一个缺点是git不会意识到您将您的分支合并到您的同事中，因为git基本上只是检查一个分支的负责人是否存在于另一个分支中，以确定它们是否合并。更改提交哈希将取消此检测。

但这可能会变得有点复杂。老实说，只要坚持合并，除非您的项目维护人员/经理有禁止合并提交的规则。

Answer 2

作为经验法则：

通常不赞成重新建立共享分支的基础。

也许一般情况不适用于你，因为我也建议：

虽然不赞成重新设置共享分支的基础，但只要每个共享分支的人都知道如果分支是重基的，那么只要每个人都得到通知，就可以这样做。

听起来，唯一会受到分支feature/dotnet6重新定位影响的人就是你，当你读完这个答案时，你就会“知道该怎么做”，所以我会说，去做吧(这也是我在你的立场下可能会做的)。

你只需要调整你计划的后半部分就行了。您打算将第二个特性分支重新定位到第一个特性分支的命令只需从以下位置更改：

git checkout feature/dotnet6
git pull

git checkout feature/dotnet6-web-api
git rebase feature/dotnet6
git push --force

至：

# Assuming you have a copy of feature/dotnet6 before it is rebased,
# skip the part where you update your local copy of feature/dotnet6
git fetch
git rebase feature/dotnet6 feature/dotnet6-web-api --onto origin/feature/dotnet6-web-api
git push --force-with-lease # using --force-with-lease is usually preferred

常规重基的问题是，您还将重播来自feature/dotnet6的所有旧的提交，这些提交不再在新的基于重基的分支上。很有可能他们都会因为他们是空的而掉下来，但也有可能这会在重新基地的过程中造成毫无意义的冲突。通过使用--onto选项，您可以指定从何处开始重放提交，在本例中，我们将将它们放到远程跟踪分支中的新版本中。此方法利用了以下事实:您以前签出了feature/dotnet6，并在该分支重新建立之前将其分支化。

为了完整起见，下面是实现目标的另一种方法，使用与rebase命令略有不同的调整：

git checkout feature/dotnet6
git fetch
git reset --hard @{u} # Note @{u} is shorthand for origin/feature/dotnet6

git checkout feature/dotnet6-web-api
git rebase --fork-point feature/dotnet6
git push --force

reset而不是pull的原因是，您不会将提交的新副本与分支上已有的旧副本合并。请注意，这与首先删除分支、获取、然后再次检查相同。此时，您的本地feature/dotnet6副本将与远程副本相同。

现在，对于重基，您将注意到我添加了选项--fork-point，它告诉Git查看您的feature/dotnet6重发，以查看是否重写了该分支的副本，如果是这样的话，请尝试为重基确定一个更好的起点。注意，只有在--fork-point被重基之前，您已经签出了feature/dotnet6的副本，那么它才能在这里起作用，而且可能是这样的。

附加说明：

1. ，您愿意重新建立这两个特性分支的事实，让我怀疑使用PR将web分支合并到dotnet6分支的价值。你们两人本质上是在合作，所以可能更有意义的是，要么等到分支完成，然后再将它公关到developing中，要么一旦完成dotnet6分支，就可以将它重新定位到developing中，然后您可以最后一次重复这个重基过程，但是在完成该PR之后最后一次使用--onto origin/developing。尽管这么说，这并不重要；如果你想把你的分支转到dotnet6分支中去，它肯定不会伤害任何东西。
2. I喜欢重新定位。我个人的偏好是，除非有充分的理由不这样做，否则总是重新定位。例如，我可能永远不会重新设置developing，因为有一个很好的理由不这样做。如果有多个人分享feature/dotnet6，我可能也不会重新定位。很容易将origin/developing合并到feature/dotnet6中并完成它。即使您不重写feature/dotnet6，您仍然可以将您的特性分支重新定位到它上，因为它不是共享的。同样，对于这个问题的上下文，我可能会重新设置两个分支的基础，因为现在您已经知道如何在之后处理花哨的重基了。