我们在Github上有一个项目，主要开发分支叫做“Master”。 一些开发人员倾向于将项目分支合并为Master。其他人倾向于将Master合并到项目分支中。
我觉得前者遵循标准协议。后者只是没有意义。我只是偏执狂，还是真的有所作为？
为了复合，项目分支随后被合并到主分支
推回到github对于那些将Master合并到项目中的人，其论点是他们需要一份Master的最新副本。我的答案;合并与它有什么关系？也许是为了获取其他人引入的变化并合并到master中？
这个过程不应该是： 1）结账大师， 2）git fetch或git pull
答案 0 :(得分：3)
开发人员不时地将主分支合并到他们的项目分支中，以确保他们不会做一些合并后无法工作的事情。这通常发生在他们的本地存储库中。
然后，当他们完成新功能时，他们将其合并到master，并推送，这将把该功能添加到公共存储库的主分支。或者他们只是将其功能分支中的内容推送到公共存储库的主分支。
git fetch只是从某个远程获取存储库的一种方法。它根本不会合并。 git pull将执行相同的操作，但也包括合并。
因此，您建议的过程最多只会将更改与本地主分支合并到公共主分支。然后，开发人员仍然需要将其本地（现在是最新的）主分支与其功能分支合并，否则他们将无法执行上述的完整性检查。
答案 1 :(得分：2)
与@richardolsson不同，我不建议他们将master合并到他们的主题分支中，如果合并我们的意思是git merge master。
他们绝对是一个好主意，他们可以更新master上发生的更新并更新他们的主题分支以反映这些更改，以避免一切都崩溃，但是git为这个特定用途提供了一些更好的工具case，git rebase。
从概念上讲，它们非常相似，并且代码库的结果通常是相同的，但使用rebase可以使项目的历史记录对于查看日志的人更加清晰，并有助于避免使用要看透的巨大的历史图表，即使那些看起来很可爱。
当你merge时，git获取合并的两个（或更多）分支的状态，尝试将它们合适地拼凑在一起，并做出反映合并已发生的提交，除非目标的HEAD branch是被合并的分支的直接后代，在这种情况下，它不需要做任何diff / patch东西，只是在彼此之上播放提交（git称之为快速转发）。
当你rebase时，git（概念上）接受目标分支，返回它与被重新分支的分支共同的最后一次提交，从该分支进行提交，然后进行从目标分支提交。一个例子可能是有序的：
您有两个分支master，其中包含提交A，B，C以及D和topic，其分支为B并提交了A，B，E和F。如果您在topic和git merge master，则最终会得到一个类似A B E F G的提交历史记录，其中G是通过合并提交的。如果您重新绑定，git首先获取topic并使其提交历史记录与master相同，然后在topic中进行提交，这样您将获得一个类似于{{1的提交历史记录}}
除了日志历史记录的清晰度之外，这样做的一个主要优点是，只要A B C D E F自您重新定位后没有发生变化，master或类似内容将始终是快进，因为所有git checkout master && git merge topic的历史记录都包含在master中。这里最大的警告是topic rebase分支，这些分支是为了公开共享，因为提交的SHA-1必须被重写，这基本上意味着一堆毫无意义的冲突。
为了这个好处，我花了一段时间才抓住了我的脑袋。我已经发现（至少对我来说，到目前为止......），“最佳”的工作流程是：
类似的东西：
not这给出了一个非常清晰的历史，并且几乎确保了如果发生破坏，它会发生在主题分支上。当你需要使用它时，它还使git checkout topic
git rebase master
# fix any conflicts, run tests, etc
git checkout master
git merge topic
等一些工具更容易使用。
无论如何，希望你发现这种方式 - 太长的答案很有用。
答案 2 :(得分：1)
更好的工作流程是，开发人员在主分支上重新设置其功能/项目分支，以避免混乱历史。
答案 3 :(得分：0)
首先要意识到的是，分支名称在技术上只对任何给定的存储库是本地的。中央version-2.0可能是我的master和您的testing。话虽如此，实际上，人们通常使用与他们最常推送的存储库相同的名称，因此将project合并到master然后推送master是标准方法。
将master合并到project将生成此树：
master A____B
project \__C_\_D
将project合并到master将生成此树：
master A____B___D
project \__C__/
请注意，两者基本相同，只是D处的分支名称与其父项的顺序相反。只要您指定git push origin project:master，如果您是第一种方式，那么在创建另一个分支之前，以某种方式更新master以指向D，您将不会注意到实践中的差异。然而，这为你自己创造了额外的心理努力，如果你不是每次都做得好的话，你可以搞砸了。将project合并到master可让您设置push的默认设置，以便轻松完成。