小团队如何掌握git工作流程

Question

想知道这种使用小团队 Git 的方法是否合理：

1. 我们有“master”分支。Git默认为我们创建此分支。
2. 开发人员 A 和 B 在本地计算机上克隆“master”。
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]。

因此，所有开发人员都在自己的本地分支上工作，并定期将内容合并到“dev”中。只有在发布时，某些人才将更改从“dev”拉入“master”。因此，“master”始终包含最新发布的代码。

这样合理吗？

谢谢！

- user291701

---

这个问题是否适合发在程序员社区？我并不是在批评这个问题，我认为它很好，但它似乎对于 Stack Overflow 来说有点“软”了？ - Dogmatixed

Answer 1

这个工作流程可能是可行的，但有一些需要考虑的问题。

它并不反映出常见的Git哲学，即每个分支代表一个“特性”或“主题”（例如，Junio Hamano关于分支目的的文章）。然而，这并不能阻止它成为您团队的可行工作流程。

反映了这种理念的另一种流程是Git Flow。

另一种流行的工作流程是GitHub开发团队使用的工作流程，直接违背了Junio关于将主分支合并到特性分支的写法，据说是为了保持心智模型更简单，并避免向开发人员解释关于变基的内容。

另一个问题是，这个工作流程不鼓励频繁的集成。因此，devA和devB可能会明显分歧，当时机到来时，开发人员可能需要做很多工作来进行合并。

Git本身并不关心，所以如果您的开发人员满意，那么您提出的方案似乎是可行的。

- Emil Sit

---

好的，谢谢您提供的这些参考资料，我现在正在查阅它们。我现在同意分歧会带来更多的麻烦问题。 - user291701

Answer 2

假设你有两个以上的开发人员，你是否希望一个开发人员能够从另一个特定的开发人员那里拉取更改，但不包括来自所有其他开发人员的更改？如果不需要，那么根本不需要创建任何开发人员分支。每个人都在自己的存储库上检查主分支；每个人都将更改推送到来源主分支；每个人在每次拉取时都会获得来自所有开发人员合并的所有推送更改。

至于源代码库中的主分支与开发分支，你可以这样做；但更常见的做法是，主分支是持续进行的工作，每个稳定版本都有自己的分支。

- smendola

---

好的，谢谢，这很有道理，我明白你关于不需要个人开发者分支的观点。说得好。 - user291701