如何将远程主分支转换为本地开发分支？

Question

我想从master那里将更新带入我的开发分支，我试图做的是应用以下命令：

 git checkout master
 git pull
 git checkout develop
 git rebase master

通过执行以上命令，我得到以下警告：

首先，快退一下，重播您的作品...

另外，我不确定是否应该执行rebase还是从母带merge到开发。 我在网上提到了几篇文章，其中一篇建议为

重新确定基准是更改应如何从层次结构的顶部向下传递，而合并则是更改如何向上流动。 （ 链接 ）

并在Microsoft 文档它暗示变基时（在实施例其表示衍合develop到master ）：

建议的方法是允许对您已进行但尚未与其他人共享的本地更改进行基础计算，但是一旦与其他人共享更改就可以合并。 这避免了重写历史记录的麻烦，同时仍使您可以在本地开发代码时轻松赶上更改。

我想知道从master分支到开发分支进行最新更改的最佳方法。

Answer 1

以我的拙见，除非您是一个有信心的git用户，否则git rebase (-i)会导致更多问题，而不是解决的问题。

请注意，例如， GitHub和Atlassian在其git flow教程中均未使用重定基。

当然，git flow只是一种方法，Atlassian在其Feature Branch Workflow文章中写道：

一旦Bill准备好接受拉取请求，就需要有人将功能合并到稳定的项目中（这可以由Bill或Mary来完成）：

 git checkout master git pull git pull origin marys-feature git push 

此过程通常会导致合并提交。 一些开发人员喜欢这种方式，因为它就像该功能与其余代码库的符号连接。 但是，如果您偏向于线性历史记录，则可以在执行合并之前将特征重新设置到母版的顶端，从而实现快速合并。

我是合并提交的支持者，我鼓励您不要使用重新定级。

Answer 2

首先，快退一下，重播您的作品...

那不是警告。 这是重新设置基准的正常输出。 如果有警告，git会告诉您（ WARNING:就像您看到的CONFLICT: ）。

注意：快进rebase并不会做任何工作-不会合并，也不会倒退HEADS。 因此，即使您使用git rebase ，git也不输出该行

至于在合并还是变基之间进行选择，在大多数情况下都是惯例。 遵循您的团队希望您使用的约定-如果他们主要将更改基于基础，然后执行。

如果没有约定，请按照您的直觉告诉您。 合并会根据时间保留提交的顺序，清楚地显示出发散和收敛，就像现实生活中发生的那样。 Rebase使历史记录看起来无缝且整洁（通过编辑历史记录，因此为什么不应该对其他牵引的分支进行重新定位）。

我尝试使用rebase。 我喜欢干净的历史记录-这个人更改了ABC，然后又更改了XYZ。

Answer 3

我会避免变基。 如果您直接将一些承诺提交给大师（不是一个好主意），并且需要带动他们发展-

git checkout develop
git merge master