git - 关于 git，您使用哪些团队工作流程？

Question

在不久的将来，我正在将我的团队从 TFS 转移到 GIT，但在此之前，我想知道其他人在将团队从集中式源代码控制(例如 CVS、SVN)转移时可能遇到的任何陷阱、TFS 等分布式源代码控制系统，如 GIT 或 Mercurial。

瞬间想到的一些问题是:

每个用户是在服务器上工作自己的分支，然后在完成后 merge ，还是只是留在他们的机器本地并在完成后推送到服务器？

所有新的开发工作应该在一个分支上完成(即“下一个版本”)还是应该针对“master”完成？

应该在服务器上的克隆中进行新的开发，然后向生产代码库发出 pull 请求，还是生产代码库的一个分支就足够了？

跟进第 3 点，如果一切都在一个分支上完成，那么是否有任何人可以控制谁可以 merge 到“master”？

还有什么我应该担心的，我没有想到在你从集中式版本控制到分布式版本控制的转变中发生的事情吗？

然而，我真正的好奇心和问题是关于您如何管理有关 GIT 和其他分布式源代码控制系统的工作流程，而不是真正适合我当前工作流程的东西。

更新:目前TFS中的开发过程是我们有一个主文件夹，然后是下一个版本的东西的分支文件夹，当下一个版本代码完成时，它会 merge 回主文件夹。团队的每个成员都拥有对整个项目的完全提交权限。我们没有任何想象的复杂过程，到目前为止，我们一直将源代码控制用作一个愚蠢的存储库。

然而，话虽如此，我正在寻找更多理想情况下的工作流程，而不是真正适合我当前工作流程的东西。这就是为什么我将问题命名为 What team workflow processes do __you__ use concerning GIT?

Answer 1

请注意，我没有在公司环境中使用过 Git，下面的答案基于我使用 Git 处理 OSS 项目的经验以及我对 Git 的理解。
另见 gitworkflows(7)联机帮助页。

• Does each user work of their own branch on the server and then merge in when done, or do they just stay local to their machines and push to the server when done?

在任何分布式版本控制系统中，在任何使用 DVCS 的工作流中，每个用户都有自己的 私有(private)存储库 ，非裸，其中他或她从事他/她的工作。通常的做法是用户在准备好之前不要发布他/她的作品。
发布一个人的工作可能意味着推送到某个中央存储库，也可能意味着推送到自己的公共(public)存储库；维护者(或同等人员)可以从此开发人员的公共(public)存储库中提取更改。
查看 Chapter 5.1: Distributed Workflows 中可能的工作流程的精美描述(带图表!)的 Pro Git. Proffesional Version Control斯科特·查康 (Scott Chacon) 的 CC 授权书。

• Should all new development work be done on a branch (i.e. "next-version") or should it be done against "master"?

推荐的工作流程(但肯定不是唯一可能的)是在单独的分支上开发每个单独的功能，所谓的 功能分支 .当功能准备就绪时，它会 merge 到“next”(开发分支)或“master”(稳定分支)中。
[...]

• Is there anything else I should worry about that I am not thinking of that happened in your move from centralized version control to distributed version control?

如果您有大型且经常更改的二进制文件，那么使用分布式版本控制系统可能更难设置；那么集中式版本控制系统可能会更好。