从“主人”转到我的分支

Question

我的存储库中的网络图如下：

M--------------M
|              ↑
├-->1---1---1--┘
|
└-->2---2

其中：M在master上被推送提交，1被推到branch-1上，2被推到branch-2上。

如您所见，来自branch-1的提交被推送，请求为“拉请求”，并合并到master中。

我在branch-2上工作，在我的任务下工作。

我需要从主人那里获得源代码才能完成它们。

第一个问题:如何将源代码从主程序传输到branch-2？

我在考虑：

git fetch origin
git rebase origin/master

或者：

git pull origin --rebase master

第二个问题:如果在第二次提交branch-2之后进行了本地更改，并且我想做上述相同的事情，我该怎么办？

Answer 1

最新消息-我忘了回答第二个问题

第一个问题

您可以将master合并到您的分支中，或者将您的分支合并到以后在主服务器上提交，或者将引入所需更改的提交合并到cherry-pick。要使用哪种工作流取决于您(以及您的团队，如果适用的话)要使用哪种工作流。

merge的优点是它不重写任何历史记录，也不重复任何提交。在某些方面，这是最简单的操作，但它确实创建了许多人认为更复杂的历史。(对于什么样的历史“更好”，没有一个客观的答案；这取决于你想如何使用历史。)如果你决定合并，你可以做这样的事情

git checkout branch-2
git merge master

这假设您的本地主人是最新的。如果不是，你可以更新它，或者做

git fetch
git checkout branch-2
git merge origin/master

默认情况下，pull是"fetch和merge“的快捷方式，所以您也可以这样做

git checkout branch-2
git pull origin/master

就我个人而言，我通常不以这种方式使用pull；我只在从自己的上游更新分支时才使用它。但这仍然是一个有效的选择。

rebase的优点是它避免了合并提交，并且创建了一些人喜欢的更线性的历史记录，并且通常不要求您保留重复提交(也就是说，它创建提交的副本，但在完成时您通常可以丢弃原始提交)。历史记录并不能反映软件是如何真正编写的，特别是它可能包含一些提交，即使您不使用“干净签入”策略，也不会干净地构建这些提交。这是一个历史重写；如果您rebase的分支已经与其他人共享(即它已经在任何时候被push编辑到原点)，那么这可能会导致problems1。

如果你决定重新建立一个基地，你可以说

git rebase master branch-2

与合并一样，您可以首先使用fetch, and updatemasterfrom its upstream or substituteorigin/masterformasteras needed. You can also configurepullto do arebaseinstead of amerge`，，但这并不是一种“安全”的配置，只有在您非常满意所有涉及的操作时，才应该这样做。

cherry-pick的优点在于它避免了创建合并提交，也避免了任何历史重写。但是，它会创建重复提交，这也会使历史变得复杂一些。如果您想要的所有更改都是在少量提交中引入到master中，那么这可能是一个很好的选择。如果您最终要将分支merge返回到master，则可能会增加合并冲突的机会，尽管它们应该不难纠正。如果您最终将分支rebase到master上，这不应该是一个问题(因为rebase具有针对cherry-pick引入的冲突的特定保护)。如果选择此方法，首先确定需要复制的提交，然后

git checkout branch-2
git cherry-pick <commit>

其中，<commit>是一个解析到您需要的提交的表达式--例如它的提交ID (散列)或相对表达式(例如，master~2将是master分支上的第二个父(即第三个到最后一个提交))。

第二个问题

如果您有未提交的本地更改，则需要稍微小心一些。git对数据丢失的最有效保护不适用于工作树副本。git通常会尽量避免删除工作树中的数据，除非您发出的命令暗示您希望它覆盖工作树。(不幸的是，有时并不清楚哪些命令会这样工作。)

因此，最安全的事情，在(合并或重新基地或樱桃采摘)之前，隐藏你的变化。

git stash

然后，恢复它们

git stash pop

请注意，这可能会导致合并冲突(因为本地更改可能会影响添加到分支的提交一样大的代码)。此外，默认情况下，这将释放所有本地更改。如果您需要将阶段性更改与非阶段性更改分开，您可以这样说：

git stash --index pop

但是，在pop期间发生合并冲突时，当给定--index选项时，命令将失败。(此时，您可以不使用--index选项，也可以通过更多涉及的循环来应用您的更改。如果需要的话，我可以进入“更多涉及的箍”。)

1一般来说，如果要对共享分支进行历史重写，则需要与每个拥有该分支副本的人进行协调。如果你不这样做，那么他们处理错误的自然尝试可能会撤销重写。人们反对在分布式repos中，这可能是不切实际的；如果它不实用，那么您就不应该重写历史。有关更多信息，请参见“从上游重基恢复”下的git rebase文档。https://git-scm.com/docs/git-rebase

Answer 2

您要做的操作最好通过合并或重基来完成。

推和拉只是你想要做的事情的偶然性。他们只是确保您的本地副本的回购是同步的是什么是在遥控器上。所有实际操作都是在本地完成的。如果您在分支上有本地提交，则将使用它们。

要让主人进入您的分支，您可以重新定位到主服务器上，也可以将母版合并到其中。如果您正在处理一个个人分支，并且您拥有强制推动非快速转发提交的权限，rebase将使您的历史保持清洁：

git rebase master
git push -f

另一方面，如果您正在协作工作，或者没有强制推送权限，请使用合并：

git merge master
git push

以上两个操作都假定您在您感兴趣的分支上。在这两种情况下，远程分支都不会以任何方式进入操作的第一部分。不同的推送选项只是考虑到您的遥控器是否可以在更改后从本地分支快速转发。