4

我发现了很多关于将分叉的 git 存储库与原始远程存储库同步的问题，但没有一个适用于我的确切问题。

假设我分叉了一个远程名称为upstream的项目，我的分叉名称是origin。我在本地有一个master和一个dev分支来跟踪master和dev的origin。

只要我不对我的分叉存储库进行任何更改，我就知道我可以通过

git checkout master
git pull upstream master
git push origin master

到现在为止还挺好。但是现在我在本地开发分支上工作，一旦完成，我想将它合并到我本地的 master 中。但首先我会让我的本地主人了解上游的变化

git checkout master
git pull upstream master
git push origin master

第一个问题：这是正确的吗？但是，我将如何处理我的本地开发分支？在将其合并到我的本地 master 之前，在我更新的master上重新定位它，或者尝试在不重新定位的情况下合并它？或者我应该尝试通过不时拉入上游/主控来使我的本地开发人员一直与上游/主控保持同步？

一旦完成，我会

git push origin master

并在本地和原点删除我的dev分支。但是现在我的主人（本地和原产地）因本地dev所做的更改而偏离了上游/主人。

第二个问题：现在与上游/主同步的正确方法是什么？难道我还只是简单地做

git checkout master
git pull upstream master
git push origin master

或者这里还有什么推荐的（例如某种形式的变基）？如果我再次创建一个分支dev，我会再次应用与第一个问题相同的策略，还是会应用其他策略？

谢谢你的帮助！

4

1 回答 1

5

问题一：

我会说任何一种方式都很好。以我的经验，这样的事情通常效果很好：

  • 当你从 upstream/master 合并到 local/master 时，rebase local/dev 是有意义的。
  • 通过在对 master 进行更改时对 dev 进行 rebase，您可以减少在要将 dev 合并回 master 时所拥有的合并/rebase 的大小。
  • 只要您始终将更改从 master 更改为 dev 就可以使用

使用 dev 完成后，您可以再次变基，然后在 master 上合并，或者直接在 master 上合并。您可能希望更改合并提交中的消息以指示合并中的内容。

问题2：

从上游合并时，只要您的本地或原点没有任何不同的更改，合并将是快进的。这基本上意味着 git 只是将来自上游的提交堆叠在您拥有的任何内容之上，并且不会合并冲突或任何东西。

正因为如此，你不需要变基或任何东西。如上所述，如果您在 dev 上工作，那么此时 rebase dev 可能是一个好主意，这样您就可以更新它。

在您有与上游不同的更改时，您将有一个实际的合并，并且如果您愿意，可以进行变基。

变基还是合并？

这主要取决于您以及您喜欢如何工作，但如果您考虑变基，请记住它会改变历史。

如果其他人正在使用 origin/master 或 origin/dev，并且您对其进行了 rebase，那么他们在尝试合并他们的工作时可能会遇到一些问题。所以一般来说，如果一个分支被不止一个人使用，你应该使用合并。如果不止一个人使用一个分支，则永远不要使用 rebase（或任何其他改变历史的东西）。

于 2011-07-06T22:27:32.040 回答