在我当前的环境中,我们有一个“干净”的构建机器,它拥有所有已提交更改的精确副本,仅此而已。
当然,我有自己的机器,有几十个文件处于“进行中”状态。
通常我需要构建我的应用程序,只需要进行一次更改。例如,我已经完成了任务 ABC,并且我想构建一个只有该更改的 EXE。
但是,在测试之前,我当然不能将更改提交到存储库。
为此,分支似乎过大了。您如何在您的环境中隔离测试构建和发布的更改?
@Matt b:所以当您等待有关更改的反馈时,您会做什么?你总是只做一件事吗?
在我当前的环境中,我们有一个“干净”的构建机器,它拥有所有已提交更改的精确副本,仅此而已。
当然,我有自己的机器,有几十个文件处于“进行中”状态。
通常我需要构建我的应用程序,只需要进行一次更改。例如,我已经完成了任务 ABC,并且我想构建一个只有该更改的 EXE。
但是,在测试之前,我当然不能将更改提交到存储库。
为此,分支似乎过大了。您如何在您的环境中隔离测试构建和发布的更改?
@Matt b:所以当您等待有关更改的反馈时,您会做什么?你总是只做一件事吗?
所以你问的是如何同时处理多个“任务”,对吧?除了分支。
您可以在本地计算机上对源进行多次检出,并在目录名称后面加上您正在处理的票证名称。只需确保根据任务在正确的目录中进行更改...
在一个工作副本/提交中混合多个任务可能会变得非常混乱,尤其是当有人需要稍后查看您的工作时。
在提交或促进任何更改之前,我更喜欢在我的本地机器/环境上进行构建和测试。
对于您的具体示例,我会在开始任务 ABC 之前检查源的干净副本,并在实施 ABC 之后,在其中创建一个本地构建。
类似的东西: git stash && ./bootstrap.sh && make tests :)
我努力让每个“提交”操作都代表一个单一的、有凝聚力的变化。有时它是一个完整的错误修复或整个功能,有时它是一个小的重构,正在走向更大的东西。没有简单的方法来决定这里的单位是什么,只是凭直觉。我也要求(请求!)我的队友也这样做。
如果做得好,您将获得许多好处:
像这样工作可以帮助减少对小分支的需求,因为你采取了一个小的、自信的步骤,验证它,提交它,然后重复。我已经讨论过如何使步骤变得小而自信,但是要使其发挥作用,您还需要使验证阶段快速进行。拥有强大的快速、细粒度的单元测试 + 高质量、快速的应用程序测试是关键。
在签入之前需要进行代码审查之前我工作过的团队;这会增加延迟,这会干扰我的小步工作方式。使代码审查成为高紧急中断工作;切换到结对编程也是如此。
尽管如此,我的大脑似乎还是喜欢繁重的多任务处理。为了完成这项工作,我仍然希望进行多项正在进行的更改。我使用了多个分支、多个本地副本、多台计算机和工具来备份挂起的更改。他们都可以工作。(而且它们都是等效的,以不同的方式实现。)我认为多个分支是我的最爱,尽管您需要一个源代码控制系统,该系统擅长快速轻松地启动新分支,而不会给服务器造成负担。我听说 BitKeeper 在这方面做得很好,但我还没有机会去看看。