如何构建仅包含众多待定更改之一的构建？

Question

在我当前的环境中，我们有一个“干净”的构建机器，它具有所有已提交更改的精确副本，仅此而已。

当然，我有自己的机器，有数十个文件处于“处理中”状态。

我经常需要只进行一项更改来构建我的应用程序。例如，我已经完成了任务 ABC，我想构建一个 EXE 仅有的 那个改变。

但当然，在经过测试之前我无法将更改提交到存储库。

对此，分支似乎有点矫枉过正。您在环境中如何隔离测试构建和发布的更改？

@马特b：那么，当您等待有关更改的反馈时，您会做什么？你总是只专注于一件事吗？

Answer 1

所以您是在问如何同时处理多个“任务”，对吗？除了分支。

您可以在本地计算机上多次签出源，并在目录名称后添加您正在处理的票证名称。只需确保根据任务在正确的目录中进行更改...

在一个工作副本/提交中混合多个任务可能会变得非常混乱，特别是当有人需要稍后检查您的工作时。

Answer 2

我更喜欢在提交或推广任何更改之前在本地计算机/环境上进行构建和测试。

对于您的具体示例，我会在启动任务 ABC 之前检查源代码的干净副本，并在实现 ABC 之后，在本地创建一个包含该副本的构建。

Answer 3

像这样的东西：git stash && ./bootstrap.sh && 进行测试:)

Answer 4

我努力使每个“提交”操作代表一个单一的、有凝聚力的更改。有时它是一个完整的错误修复或整个功能，有时它是一个小的重构，以实现更大的目标。没有简单的方法可以仅凭直觉来决定这里的单位是什么。我也要求（恳求！）我的队友也这样做。

如果做得好，您将获得许多好处：

• 您可以为变更编写高质量、详细的描述。
• 阅读每个更改的描述的第一行可以让您了解代码的流程。
• 更改的差异很容易阅读和理解。
• 如果更改引入了错误/构建中断/其他问题，则很容易隔离、理解并在必要时退出。
• 如果我在变革进行到一半时决定中止，我也不会损失太多。
• 如果我不确定下一步如何进行，我可以在几种方法中每种方法上花几分钟，然后选择我喜欢的一种，放弃其他方法。
• 我的同事更快地接受了我的大部分更改，从而极大地简化了合并问题。
• 当我对一个大问题感到困惑时，我可以采取一些我有信心的小步骤，边走边检查它们，从而使大问题变得更小。

像这样的工作可以帮助减少对小分支的需求，因为您采取了一个小的、自信的步骤，验证它，提交它，然后重复。我已经讨论过如何使步骤小而自信，但要使其发挥作用，您还需要使验证阶段快速进行。拥有强大的快速、细粒度的单元测试+高质量、快速的应用程序测试是关键。

我之前工作过的团队在签入之前需要进行代码审查；这会增加延迟，影响我的小步工作风格。让代码审查成为一个高度紧急的中断是有效的；转向结对编程也是如此。

尽管如此，我的大脑似乎还是喜欢繁重的多任务处理。为了实现这一目标，我仍然需要进行多个正在进行的更改。我使用了多个分支机构、多个本地副本、多台计算机，并且 备份待处理更改的工具. 。它们都可以工作。（它们都是等效的，以不同的方式实现。）我认为多个分支是我最喜欢的，尽管您需要一个善于快速轻松地启动新分支的源代码控制系统，而不会给服务器带来负担。我听说 BitKeeper 在这方面很擅长，但我还没有机会去看看。