在不久的将来，我正在将我的团队从TFS转移到GIT，但在此之前我想了解其他人在从集中式源控制中移动团队时可能遇到的任何陷阱CVS，SVN，TFS等等到GIT或Mercurial等分布式源控制系统。
时间关注的一些问题是：
每个用户是否在服务器上运行他们自己的分支，然后在完成后合并，或者他们只是保持本地机器并在完成后推送到服务器？
所有新开发工作是否应在分支机构（即“下一版本”）上完成，还是应该针对“主”进行？
是否应在服务器上的克隆中进行新开发，然后向生产代码库发出拉取请求，或者生产代码库的分支是否足够好？
跟进3号，如果在某个分支上完成所有操作，无论如何都要控制谁可以合并到“master”中？
还有什么我应该担心的，我不会想到从集中版本控制转向分布式版本控制时发生的事情吗？
然而，我真正的好奇心和问题涉及如何管理有关GIT 和其他分布式源代码控制系统的工作流程，而不是真正适合我当前工作流程的东西。
更新：目前TFS的开发过程是我们有一个主文件夹，然后是下一个版本的分支文件夹，当下一个版本的代码完成时，它会被合并回来到主文件夹。团队的每个成员都拥有整个项目的完全提交权。我们没有任何想象力的复杂过程，直到现在我们使用我们的源代码控制只是一个愚蠢的存储库。
然而，话虽如此，我正在寻找更多理想情况的工作流程，而不是真正符合我当前工作流程的东西。这就是为什么我标题为What team workflow processes do __you__ use concerning GIT?
答案 0 :(得分：6)
从您的问题我觉得您的心态仍然是集中式版本控制系统。在分布式系统中，服务器不再是“工作场所”，而只是集体工作的一面镜子。因此，它甚至不是必需的。
通常，中央存储库只有master分支和发布标记。它应该只反映每个人的共同因素。分布式系统中的分支是非常私密的，因此应保持在本地。
在我的私人存储库工作中，我有以下分支：
master 是中心master的精确反映。我从来没有投入过。相反，我只是从中央镜子拉到我的master。develop-* 是一组从release分支分支出来的功能（工作）分支。例如，我可能有一个名为develop-foo_performance的分支，我在其中调整类Foo的性能。或者，我可能有一个名为develop-cosmetics的分支，我在那里积累了一些小的化妆品提交。对于非常具体的任务，这些大多是短期分支。这些是草案分支;我一直在这里提交 ，自由编写提交消息，并且没有花时间考虑“这个改变是否值得提交”。这是我的私人错误隐藏历史记录跟踪Ctrl-S。release 是我准备发布的壁垒。当我为分支Foo上的develop-foo_performance的性能调整编写我的特定想法时，我可能会有一组无组织的提交，在各个方向进行实验。我将这些提交重新绑定到release分支，将它们压缩为逻辑的面向功能的提交 - 通常是单个提交。这个壁球抛弃了所有未在最终状态中结束的代码，因此release显示的历史非常干净且线性;所有的实验都消失了，好像我是一个完美的开发人员，而不是可以看到未来，从来没有犯过错误，并且有很棒的描述性提交。在一天结束时，我将release分支推送到中央镜像，然后获取远程master并将其合并到我的master。napkin 是我的个人笔记分支。它的根提交与master的提交不同。我从来没有将这个分支合并或重新组合成任何其他分支，从不推动或拉入它，从不在这里合并任何东西。在这里，我存储我的待办事项文件，我发现的错误，我的个人笔记，想法，思考问题或任何其他自由撰写文档。这是一个不相交的分支，这是我个人的做事方式：没有人见过它。它让我有条不紊和清晰。对于我所拥有的任何项目，无论是在工作中还是在家中，这些都是我拥有的唯一分支机构。我只创建新的develop-*分支并删除完整和失败的分支。其他分支永远不会死亡，也永远不会变质。请注意，当我将远程master合并到我的master时，合并应该是快进的。这是因为我从不进入我自己的master - 只是进入它。
此工作流程支持集成开发人员;负责将其他人的工作集成到中央master分支的开发人员。如果人们从未进入他们的个人master分支，那么他们就可以保证他们的个人master看起来与生产代码库完全相同。它是一种安全网，如果他们需要一个干净的代码库，人们总是可以从中分支出来。
如果两位开发人员想要分享实验，那么他们可以发送对方的拉取请求，或通过git format-patch的电子邮件发送提交。这是最好的分布式工作：沟通在同伴之间，不关心实验的人不必看到它。他们保持专注，项目看起来更小，更简单。
答案 1 :(得分：4)
请注意，我没有在公司环境中使用Git，下面的答案基于我使用Git处理OSS项目的经验，以及我对Git的理解。
另见gitworkflows(7)联机帮助页。
- 每个用户是否在服务器上运行他们自己的分支，然后在完成后合并，或者他们只是保持本地机器并在完成后推送到服务器？
在任何分布式版本控制系统中，以及在使用DVCS的任何工作流程中，每个用户都有自己的私有存储库，非裸露，他或她将其投入使用/她的工作。通常的做法是用户在准备好之前不要发布他/她的作品。
发布一个人的工作可能意味着推送到某个中央存储库，或者它可能意味着推送到自己的公共存储库;从这个开发人员的公共存储库中，维护者（或等效的）可以进行更改。
查看由Scott Chacon撰写的Chapter 5.1: Distributed Workflows CC许可书籍Pro Git. Proffesional Version Control中可能的工作流程的详细说明（附图！）。
- 是否所有新的开发工作都应在分支机构上完成（即“下一版本”），还是应该针对“主”进行？
推荐的工作流程（但肯定不是唯一可行的工作流程）是在单独的分支上开发每个单独的功能，即所谓的功能分支。当功能被认为准备就绪时，它将合并到“下一个”（开发分支）或“主”（稳定分支）。
[...]
- 还有什么我应该担心的，我不会想到从集中版本控制转向分布式版本控制时发生的事情吗？
如果您有大量且经常更改的二进制文件，那么使用分布式版本控制系统可能更难设置;然后集中版本控制系统可能会更好。
答案 2 :(得分：2)
我在我们的组织中使用了这个工作流程：http://nvie.com/posts/a-successful-git-branching-model/
我们通过gitolite建立谁可以对什么分支做什么的管理。
它是一个很好的“尾灯，可以通过雾”。有了Git给你的无穷无尽的选择，很难自己决定你的工作流程应该是什么。从这个开始并适应。它对我们很有用。我们正在使用带有OSS风格的.net堆栈（NHibernate等）
答案 3 :(得分：0)
Git塑造您的需求，而不是相反（与集中式源控制系统一样）。
如果您告诉我们您如何管理您的开发和发布，我们可以告诉您GIT中的哪些工作流程适合您。
编辑： 至于更新，您可以在git中轻松完成此工作流程。问题是您希望从源管理工具中获得更多内容。仅仅因为我们想要改变而做出改变并不是一个好主意。