git工作流：每个人都有一个分支，还是每个人都有一个主分支？

使用git与多人合作时，效果更好吗

让每个人都在大师中工作，并在彼此的大师之间融合，或

让每个人都在自己的分支机构工作

在我看来，在（1）的情况下，虽然每个主控器都充当一个分支，但每个人都希望以一个基本线性的流程在彼此的工作之间进行合并，而在（2）中，每个人都希望将一个公共主控器合并到他们的分支中，并在准备就绪时将更改从他们的分支推送到公共主控器中

有使用git在中大型团队中工作经验的人可以发表意见吗？什么最适合您的团队？我想第三种选择是始终使用功能分支而不是人员分支，尽管从这个问题的角度来看，我认为这与（2）的情况基本相同

---

我想象在（1）和（2）中，一个人负责将更改拉到“官方”主控器。如果一个以上的人推式访问官方主机，这将如何进行？

git中的分支名称是存储库的本地名称

push

和

pull

可以配置为匹配远程存储库中的相同名称，但这是可选行为。如果您有一个中央存储库，您希望

master

有一个明确的存储库。个别开发人员在其本地存储库上所称的工作分支实际上是一个品味问题。一些将使用本地

主
作为其工作分支，而另一些将使用单个命名的dev分支

如果您的开发人员能够胜任，那么真正明智的方法是使用功能或主题分支，这样您就可以使用“自动Frotzification功能”而不是“Mike's work”分支可以理智地推送和交换的分支，而无需每个人都进行大量的早期来回合并。
DVCS将该出版物作为一种工具介绍

这意味着DVCS中的分支机构有两个角色：

经典的一个：：隔离分支中代码的历史记录（修订列表）
新的一个：发布：您将您的承诺从一个回购协议复制到另一个回购协议
Git允许“私有提交”，即您可以提交任意数量的内容（然后可以）。

如果在master中执行此操作，则不利于发布：因为在克隆repo时，master是默认可见的分支，所以任何克隆repo的人都不会获得稳定状态，而是正在进行的工作的快照

私有提交意味着：在未发布的分支中提交。

你想叫什么就叫什么

任何要推/拉的分支都不应在资源名称之后调用（如“
VonC_分支
”），而应始终在功能或更一般的发布管理主题之后调用（如“
public
”、“
next
”、“
patchV1
”、…）

私有分支和公共分支之间的区别在于您在每个分支中允许的提交历史：


在一个私有分支中，您需要多少次提交（只需分配正确的注释，以便通过
rebase--interactive
与
！fixup
和
！squash
操作促进未来的重新排序）
公共分支中的“一致”提交（每个提交都是完整的，表示至少可编译且可测试的稳定状态，即使这些测试失败）

例如，一个主分支会有比这更严格的标准（比如“测试必须通过”）

因此，要决定如何在Git中使用分支，您需要考虑发布方面。
对于一个中型到大型团队，您最有可能希望拥有集中的存储库，以及“官方”
master
分支

另一个受欢迎的选择是有一个集成商，他基本上是开发商和中央回购之间的中介。你如何决定这一点取决于你的团队决定什么是最合适的方法。有一篇很好的文章总结了这两种方法之间的差异

使用共享回购协议，这取决于开发人员的个人偏好（以及一些团队协议）是直接提交到本地
主机
，还是使用单独的
开发
分支。我的想法是，在
开发
分支中保留本地更改是一个更好的选择，但对于习惯于集中式SCM的开发人员来说稍微麻烦一些

单独的
dev
分支的好处是，只需在
master
上运行
git pull
，就可以更容易地跟踪代码库中的新提交。干净的master允许dev在必要时始终签出最新的公共代码。如果
pull
在
master
中进行更改，它将合并到中ode>origin/master
分支到未发布的提交上。这将在
master
中创建一个新的合并提交，并且如果将更改推回到
master
，则该操作将可见。这可能是您想要的，但它会使提交历史看起来有些混乱

使用
dev
分支，您可以轻松地针对
master
重新设置基础，以保持提交历史记录的线性。如果没有
dev
分支，则
master
中的
git pull--rebase
将具有相同的效果，但很容易忘记这一步

基本上，使用私有跟踪分支（如
dev
）让开发人员在如何接受本地分支机构的公共更改方面有更多的灵活性。这也使集中回购更容易避免过度的合并提交。唯一的缺点是，它需要开发人员做出一些额外的努力，但从长远来看，这将提高git的最终利用率。
是的，wh在你第一段的陈述中，基本上是我的问题陈述。我想问的是你会推荐什么政策？如果你有一半的开发经验