获得小团队的git工作流程

Question

想知道这是否是在小团队中使用git的合理方法：

1. 我们有“主”分支。 Git默认为我们创建了这个分支。
2. 开发人员A和B将“master”克隆到他们的本地计算机。
3. 开发人员A运行：[git branch devA]以创建本地分支。他们通过运行：[git checkout devA]来切换到它。
4. 开发人员B运行：[git branch devB]以创建本地分支。他们通过运行：[git checkout devB]来切换到它。
5. 对于Developer A将其本地分支转换为远程分支，它们将运行：[git push origin devA]。开发人员B对他们的本地分支做同样的事情。
6. 现在如果使用GitHub，我们会在项目页面上看到这两个远程分支。
7. 两个开发人员都对其本地分支进行了更改，运行[git push]会将他们的提交推送到各自的远程分支（我们会在github上看到这一点）。

这对我来说似乎是一个合理的工作流程。现在是时候让开发人员将他们所有的工作合并到他们正在开发的应用程序版本中。我的理解：

1. 开发人员A希望将开发人员B的更改纳入其分支。开发人员A将运行：[git pull origin devB]。
2. 我们可能会创建另一个名为“dev”的远程分支，它作为每个人更改的中央存储库：[git branch dev]，[git push origin dev]。
3. 其中一位开发人员切换到分支“dev”。他们将每个人的变化都拉进去：[git pull origin devA]，[git pull origin devB]。所有冲突都是固定的等等。
4. 在“dev”上修复所有冲突后，我们切换到分支“master”，并将“dev”拉入其中：[git branch master]，[git pull origin dev]。

因此，我们的想法是所有开发人员都在自己的本地分支上工作，并定期将内容合并到“dev”中。只有在发布时才有人将“dev”的变化拉到“master”。所以“master”总是包含最后发布的代码。

这看起来合理吗？

谢谢！

Answer 1

这个工作流程可能会很好，但它有一些你可能想要考虑的要点。

它没有反映出一个共同的Git哲学，即每个分支代表一个“特征”或“主题” - 工作的价值（例如，参见Junio Hamano on the purpose of branches）。但是，这并不能阻止它成为您团队的可行工作流程。

反映这一理念的流行工作流程是git flow。

另一个流行的工作流程是workflow that the GitHub dev team uses，它直接违背了Junio关于将主人兼并到功能分支的内容，有利于保持心智模型更简单并避免向开发人员解释变基。

另一个问题是此工作流程不鼓励频繁集成。所以devA和devB可能会有很大分歧，开发人员可能需要做很多工作才能合并。

Git本身并不关心如果您的开发人员感到满意，那么您的建议似乎是可行的。

Answer 2

假设您有两个以上的开发人员，您是否希望一个开发人员能够从其他特定开发人员那里获取更改，但不包括来自所有其他开发人员的更改？如果没有，我根本不需要创建任何开发者分支。每个人都在自己的存储库中检查主人;每个人都在掌握起源;每个人都可以获得所有推动的变化，并与所有开发人员合并。

至于原点上的主人与开发分支，你可以这样做;更常见的是，我认为，master是正在进行的工作，每个稳定版本都有自己的分支。