在不久的将来,我正在将我的团队从TFS转移到GIT,但在此之前,我想了解其他人在从CVS,SVN等集中源控制中移动团队时可能遇到的任何陷阱,TFS等到GIT或Mercurial等分布式源控制系统.
一些问题立刻引起了时间的关注:
每个用户是否在服务器上运行他们自己的分支,然后在完成后合并,或者他们只是保持本地机器并在完成后推送到服务器？
是应该在一个分支上完成所有新开发工作(即"下一版本")还是应该针对"master"进行？
是否应该在服务器上的克隆中进行新的开发,然后向生产代码库发出拉取请求,或者生产代码库的分支是否足够好？
跟进3号,如果在分支上完成所有操作,无论如何都要控制谁可以合并到"主"？
还有什么我应该担心的是我没有想到从集中版本控制到分布式版本控制的过程中发生了什么？
然而,我真正的好奇心和问题涉及您如何管理有关GIT和其他分布式源代码控制系统的工作流程,而不是真正适合我当前工作流程的东西.
更新:目前TFS中的开发过程是我们有一个主文件夹,然后是下一版本的分支文件夹,当下一版本代码完成后,它将合并回主文件夹.团队的每个成员都拥有整个项目的完全提交权.我们没有任何想象力的复杂过程,直到现在我们使用我们的源代码控制只是一个愚蠢的存储库.
然而,话虽如此,我正在寻找更多理想情况的工作流程,而不是真正符合我当前工作流程的东西.这就是我提出这个问题的原因What team workflow processes do __you__ use concerning GIT?
从您的问题来看,我觉得您的心态仍然是集中式版本控制系统.在分布式系统中,服务器不再是"工作场所",而只是集体工作的一面镜子.因此,它甚至不是必需的.
通常,中央存储库只有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.这是最好的分布式工作:沟通在同伴之间,不关心实验的人不必看到它.他们保持专注,项目看起来更小,更简单.
请注意，我没有在公司环境中使用过 Git，下面的答案基于我使用 Git 处理 OSS 项目的经验以及我对 Git 的理解。
另请参阅gitworkflows(7)联机帮助页。
- 每个用户是否在服务器上自己的分支上工作，然后在完成后合并，或者他们只是停留在其计算机本地并在完成后推送到服务器？
在任何分布式版本控制系统中，以及在使用 DVCS 的任何工作流程中，每个用户都有自己的非裸露的私有存储库，他或她在其中存放他/她的工作。通常的做法是用户在准备好之前不要发布他/她的作品。
发布一个人的作品可能意味着推送到某个中央存储库，也可能意味着推送到自己的公共存储库；维护者（或同等人员）可以从该开发人员的公共存储库中提取更改。
在第 5.1 章： Pro Git的分布式工作流程中查看可能的工作流程的精彩描述（带有图表！） 。Scott Chacon 撰写的专业版本控制CC 许可书籍。
- 所有新的开发工作应该在分支（即“下一个版本”）上完成还是应该针对“主版本”完成？
推荐的工作流程（但当然不是唯一可能的工作流程）是在单独的分支上开发每个单独的功能，即所谓的功能分支。当功能被认为准备就绪时，它会被合并到“下一个”（开发分支）或“主”（稳定分支）中。
[...]
- 还有什么我应该担心的，我没有考虑到您从集中式版本控制转向分布式版本控制时发生的情况吗？
如果您有大量且经常更改的二进制文件，那么使用分布式版本控制系统可能更难设置；那么集中式版本控制系统可能会更好。
| 归档时间： |
|
| 查看次数： |
1024 次 |
| 最近记录： |