git工作流:每个人都有一个分支,还是每个人都有一个主?

push pull master 必须有明确的证据。个别开发人员所称的本地存储库上的工作分支实际上是一个品味问题。有些人会在当地 是他们的工作分支,其他人将使用一个名为dev的分支。

如果您的开发人员能够胜任,那么真正明智的方法是使用特性或主题分支,这样您就不必拥有“Mike's work”分支,而是拥有一个“work on autofrotzification feature”分支,它可以被合理地推送和交换,而无需每个人都进行大量的早期前后合并。

DVCS将该出版物作为 othogonal dimension to branching .

这意味着DVCS中的分支有两个角色:

1. code isolation
2. 新的一个:发布:你将你的承诺从一个回购到另一个回购。

Git允许“私有提交”(private commits),即您可以提交任意多的内容(然后您就可以) clean your history of commits
如果在master中执行此操作,则不利于发布:因为在克隆repo时,默认情况下master是可见的分支,所以任何克隆repo的人都不会获得稳定状态,而是正在进行的工作的快照。

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

任何要推/拉的分支都不应该在资源名之后调用(比如' VonC_branch '),但总是在功能或更一般的发布管理主题之后(如' public ', ' next ', ' patchV1 ', ...)

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

• rebase --interactive 具有 !fixup 和 !squash
• 公共分支中的“一致”提交(每个提交都是完整的,表示一个稳定状态,至少可以编译并可以测试,即使那些测试失败)
  例如,主分支会有比这更严格的标准(比如“测试”) 通过)

因此,要决定如何在Git中使用分支,需要考虑发布方面。

对于一个中型到大型的团队,您很可能希望有一个集中的存储库,带有“官方” master 分支机构。

另一个流行的选择是有一个集成商,他基本上是开发商和中央回购之间的中间人。你如何决定这一点取决于你的团队认为什么是最合适的方法。有一篇很好的文章论述了这两个问题的不同之处 Pro Git book .

主人 ,或使用单独的 dev 开发

分离的好处 开发 分支使得只需运行 git pull 在 主人 . clean master允许开发人员在必要时总是检查最新的公共代码。如果你 pull 随着 主人 origin/master 分支到未发布的提交。这将在中创建一个新的合并提交 主人 主人 . 也许这就是你想要的,但是它会让提交历史看起来有些混乱。

用一个 开发 分支可以轻松地根据 主人 分支机构,a git pull --rebase 在里面 主人 会有同样的效果,但很容易忘记这一步。

基本上,使用私有跟踪分支(如 开发 )使开发人员在如何接受本地分支的公共更改方面有更多的灵活性。这也使得集中回购不存在过度的合并提交变得更容易。唯一的缺点是它需要开发人员付出额外的努力,但从长远来看,这将提高git的最终利用率。