部署Git工作流挂了一个小团队

Question

知道如果这是一个合理的方法来使用Git有一个小团队：

1. 我们有“主”分支。 Git默认为我们创建这个分支。
2. 开发人员A和B将“主人”克隆到他们的本地机器。
3. 开发人员A运行：[git branch devA]创建本地分支。他们通过运行[git checkout devA]来切换到它。
4. 开发人员B运行：[git branch devB]创建本地分支。他们通过运行[git checkout devB]切换到它。
5. 对于开发者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]。

所以这个想法是，所有的开发人员在他们自己的本地分支上工作，并定期合并到“开发”的东西。只有在发布时，才会有人从“开发者”变成“主人”。所以“主”总是包含最后发布的代码。

这是否合理？

谢谢！

Answer 1

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

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

反映这一理念

一种流行的工作流程是git flow。

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

另一个问题是，此工作流程不鼓励频繁集成。所以德瓦和发展局可以显著分歧，开发商可能需要做的工作很多在时机成熟时合并。

Git本身并不在乎，所以如果你的开发者很开心，那么你的建议似乎可行。

Answer 2

假设您有两个以上的开发人员，您是否希望一位开发人员能够从其他特定开发人员那里获取更改，但不包括来自所有其他开发人员的更改？如果没有，我不认为有必要创建任何开发者分支机构。每个人都会检查以掌握自己的存储库;每个人都在推动原点的掌握;每个人都可以获得所有推送的更改，从所有开发人员合并到每个推送。

至于在起源的主对开发分支，你可以这样做;更典型的是，我认为，主人是正在进行的工作，每个稳定版本都有自己的分支。