我目前在一个项目中工作,从一开始分支和合并就一直表现不佳。为了改变这种情况,我们已经讨论了很多不同的方法。我认为每个人都有自己关于如何做这种事情的哲学,这里似乎也是如此。
我们讨论过的一件事是按功能进行分支。我们恰好对这种特定方法的优点和缺点持有非常不同的观点。
你有这方面的经验吗?是否有效?你遇到了问题 - 是什么问题?
我知道这个问题不会有一个正确的答案,但我很有兴趣听听世界各地其他开发人员的意见,而stackoverflow似乎是一个很好的地方。
我目前在一个项目中工作,从一开始分支和合并就一直表现不佳。为了改变这种情况,我们已经讨论了很多不同的方法。我认为每个人都有自己关于如何做这种事情的哲学,这里似乎也是如此。
我们讨论过的一件事是按功能进行分支。我们恰好对这种特定方法的优点和缺点持有非常不同的观点。
你有这方面的经验吗?是否有效?你遇到了问题 - 是什么问题?
我知道这个问题不会有一个正确的答案,但我很有兴趣听听世界各地其他开发人员的意见,而stackoverflow似乎是一个很好的地方。
这里是我发现的一种平衡生产力和版本控制安全性的模式(适用于大约25个开发人员和3个测试人员的团队):
在同一分支上工作: 开发人员可以相对安全地在同一Dev(或“集成”)分支上直接工作,前提是他们的代码是松散耦合或无关的。修复bug和非破坏性更改很好地适合在这里(较低的风险会影响其他开发人员)。持续集成构建和门禁构建是缓解多个开发人员在同一分支上工作的风险的两个最佳实践。 提示:功能切换可以用来进一步避免需要创建分支,但是确保测试/维护切换行为的开销不会比使用分支更加危险。
Shelvesets: 使用版本控制系统的功能将待处理的更改保存在特定于每个开发人员的原型分支中。如果只有一个人需要在集成/Dev分支之前开发和测试该功能,那么在TFS(Team Foundation Server)中签入的开发人员可以使用shelvesets而不是个人分支(或许多微型功能/任务分支)。我相信其他版本控制系统也有类似的构造。 反模式:本地工作区自动为每个开发人员提供临时隔离...但是开发人员需要经常/每天在源代码控制中的某个位置签入他们的更改,以防止丢失几天或更长时间的本地工作。
短期分支: 当你确实需要一个用于隔离的分支(例如用于多个开发人员需要开发的破坏性功能)时,创建短期功能分支是一种不错的方式。我建议使用分支命名约定,以使分支使用在一段时间内得到很好的定义和唯一性。
以上工作流的主要优势在于最小化合并税(花费时间将前/后向集成(向下/向上合并)),而不是开发直接改善客户满意度的功能。
示例场景: 新的“酷炫”功能会破坏现有的功能和构建,直到完成为止。它还需要2个以上的开发人员在同一代码库上进行协作(消除使用Shelveset的选项)。"酷炫"的开发所有者创建名为Cool1的分支,然后开发和集成测试功能的第一个版本。开发所有者每天(绝对最多每周一次)负责合并父级更改。确认准备好合并(父级合并子级(FI),运行所有UT和核心验收测试仍然通过)。合并到父级(RI),然后确认在父分支中运行正常(所有UT和核心验收测试都通过),然后删除Cool1功能分支(清理)。
在将Cool功能合并到开发/集成分支后更全面地测试该功能。(由于测试资源有限,请避免为每个分支使用完整的测试环境。)如果需要修复漏洞和战术性增强/重构Cool,则直接在Dev分支中完成(当分配的开发人员需要很多天本地开发/测试才能提交时使用Shelveset)。如果以后需要对Cool进行大型(多开发人员)重构,则创建一个新的Cool2分支。
TFS2010移动/重命名说明: TFS 2010移动和重命名行为已更改(从TFS 2008),以使移动和重命名=“将分支移至新名称/位置,然后将原始项标记为已删除”。这意味着,如果您不想在源代码控制\Dev\中看到这些非活动功能分支,只需删除它们即可,而不是将分支移动到其他文件夹中。这也意味着启用查看已删除文件夹的开发人员将始终将这些已删除(或已移动或已重命名)短暂分支视为“幽灵”,这可能会导致混乱。(这是如何查看历史记录或取消删除已删除项的方法。)
话虽如此,我并不认为特性分支是不好的,但它确实依赖于每个人都理解源代码控制和合并的概念,并确保分支与主分支不会相差太远,导致一次大规模的合并。
我最近参加了Thoughtworks举办的一次会议,Martin Fowler在会上讨论了这个问题。讲座的重点是持续交付以及如何帮助克服缓慢和风险高的部署。请查看http://www.thoughtworks.com/events/thoughtworks-continuous-delivery-devops或搜索“连续交付”以获取更多信息。
如果有更多的团队在他们自己的分支上工作,以合并目标为中心,你需要更好的沟通来处理冲突。
要注意代码中高频率变动、耦合和常见区域。这些将是争议的焦点。
按特性分支可以在TFS中有效地完成,但是像开发中的任何事情一样,你越复杂,就会产生越多的开销。
Git比TFS好得多。我已经使用git超过7年了,之前用过TFS。最近我换了一份工作,必须使用TFS。只有一个开发分支并且所有开发人员都在同一个开发分支上工作,并不允许进行适当的代码审查。我喜欢在git中代码审查是一个正式的过程。
使用git,我通过创建与特性/工作项相关的本地分支来工作。完成工作后,您可以将其推送到远程分支。然后,从远程分支发起拉取请求到您的dev / integration分支。一旦拉取请求得到审查,评审人员将合并PR到dev分支。这对我非常有效。