Question

对于GIT来说我还很陌生，并且正在寻找一种方法来管理我们的4个环境中的分布式代码开发团队之间的源代码，这些团队致力于错误修复和新开发，同时尽可能保持精简和直接。我们有两个Sprint团队在处理相同的源代码。

话虽如此，跨环境只有一个主分支会不会有任何问题，这样我们就不必处理不同分支之间的代码合并了吗？我没有看到只有一个主机的许多示例模型，因此不确定结果如何。

谢谢。

Answer 1

分支名称的数量基本上无关紧要。无论您有多少个分支名称，您都必须处理合并代码-合并只是并行工作的副产品，其中人A在代码上工作（在存储库A的副本中），而人B也在代码上工作（在B的存储库副本中）。然后，必须在某人[em] （甲，乙，第三人或所有这些人的某种集合）中共同努力，以结合来完成甲和乙的工作。

如果您为并行工作的每一位都提供分支名称，那么这种组合实际上很容易，因为否则您拥有的名称就是原始的Git哈希ID，它们看起来是完全随机的，完全不适合人际交流。不要担心分支名称：它们会有所帮助。

Answer 2

在整个环境中只有一个主分支会不会有任何问题，这样我们就不必处理不同分支之间的合并代码了

您只能使用一个分支，但这不会阻止合并的发生-至少在有多个开发人员为代码贡献代码的情况下。实际上，当每个人都在同一个分支上工作时，例如master，您会发现自己更频繁地合并，因为每次您想push时，首先都必须整合上游变更。每当您说出git pull来使同事的贡献进入您的工作分支时，git实际上就是在做fetch，然后是merge。

但是，如果每个开发人员（或正在使用的功能）至少有一个分支，则每个开发人员都将推入自己的分支并决定何时合并。这通常比不准备在您不准备合并时强制合并要方便得多。

Git非常擅长合并。您不必担心。

摘要：是的，您只能使用master，但这不会使您的生活更轻松，我不建议这样做

Answer 3

话虽如此，跨环境只有一个主分支会不会有任何问题，这样我们就不必处理不同分支之间的代码合并了吗？我没有看到只有一个母版的许多示例模型，因此不确定结果如何。

您对此并没有太多了解，因为它抛弃了Git的优势之一，廉价的分支机构和轻松的合并。您仍然会合并，因为push和pull将不得不将您的本地主服务器与远程主服务器合并，但是每个人只要愿意，就会将其推向master，每个人的工作都会混合在一起，master会变得一团糟。

但是您在正确的轨道上。您要 避免长期运行的分支 ，而不是避免分支。没有develop或qa分支。将master作为单个长期运行的分支是一个很好的工作流程。

诀窍是 永远不要直接提交给master 。相反，您始终想在 短暂的“功能分支” 中工作，这些分支已合并到master中。从名称上来说，功能分支是针对一个明确指定的功能（或错误）的。该功能的所有工作和质量检查均在功能分支上进行。完成后，它将合并到master中。 master可以直接投入生产，也可以标记特定版本。

这可以使master始终保持良好的状态，可以进行加工和释放。它可以使进行中的工作与master清晰地分开，从而避免将错误的代码错误地放入master中。它减慢了master更改的频率，使每个人都更易于协调。而且，您可以同时处理许多功能，同时将所有功能清楚地分开。

保持简单并避免复杂的合并的诀窍是始终使用master将分支保持在最新的rebase上。

基本工作流程如下：

更新您的master：git checkout master; git pull --rebase
为您的功能创建并签出功能分支：git checkout -b issue/#123
编辑，工作并提交到功能分支。
定期更新master。
1. 使您的master保持最新。
2. 在master上重写您的工作：git checkout issue/#123; git rebase master
完成工作，进行测试，进行质量检查等后，...
1. 使您的master保持最新。
2. 在master上重写您的工作。
3. 上次测试您的分支。这与合并后的代码完全相同，因为没有要合并的内容。
4. 将其合并到master中。该合并不会改变任何内容，您已经处于最新状态，但是对历史很重要：git checkout master; git merge --no-ff issue/#123
删除功能分支：git branch -d issue/#123
转到1

请注意，更新是通过rebase完成的。这样可以避免一堆“簿记”合并混淆了历史记录。相反，您使用rebase假装您的分支始终写在最新的master上。我建议您在.gitconfig

中进行设置

[pull]
        rebase = preserve

然后git pull总是作为变基完成，但会保留分支。这是完全安全的。

最终的真实合并使用--no-ff（无快进）完成，以确保合并完成，从而使分支保留在历史记录中。合并提交也是一个用于编写分支的内容并提供指向已解决问题的链接的地方。

结果是这样的历史记录：

                            J - K - L [issue/#123]
                           /
A ---------- E ---------- I [master]
 \         /  \         /
  B - C - D    F - G - H

这是两个完整的功能B - C - D和F - G - H，以及一个打开的功能分支J - K - L。出于考古目的，这些分支仍然存在，即“特征泡沫”，因此未来的开发人员知道B-C-D是作为一个单元完成的，可以参考合并提交E以获得更多信息。尽管所有分支历史都是线性的； git log将以正确的顺序报告提交。

这不仅仅是简单地致力于master的工作，但是它可以产生干净，简单的历史记录，高质量的master作为您的工作基础，并避免开发人员陷入崩溃。版本控制是一种工具，就像您的编辑器或Shell一样，要有效使用它需要花费一些精力。

GIT分支-我们可以仅靠大师生存吗？

3 个答案: