version-control - 您如何制作仅包含众多待定更改之一的构建？

Question

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

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

通常我需要构建我的应用程序，只需要进行一次更改。例如，我已经完成了任务 ABC，并且我想构建一个只有该更改的 EXE。

但是，在测试之前，我当然不能将更改提交到存储库。

为此，分支似乎过大了。您如何在您的环境中隔离测试构建和发布的更改？

@Matt b：所以当您等待有关更改的反馈时，您会做什么？你总是只做一件事吗？

Answer 1

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

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

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

Answer 2

在提交或促进任何更改之前，我更喜欢在我的本地机器/环境上进行构建和测试。

对于您的具体示例，我会在开始任务 ABC 之前检查源的干净副本，并在实施 ABC 之后，在其中创建一个本地构建。

Answer 3

类似的东西： git stash && ./bootstrap.sh && make tests :)

Answer 4

我努力让每个“提交”操作都代表一个单一的、有凝聚力的变化。有时它是一个完整的错误修复或整个功能，有时它是一个小的重构，正在走向更大的东西。没有简单的方法来决定这里的单位是什么，只是凭直觉。我也要求（请求！）我的队友也这样做。

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

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

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

在签入之前需要进行代码审查之前我工作过的团队；这会增加延迟，这会干扰我的小步工作方式。使代码审查成为高紧急中断工作；切换到结对编程也是如此。

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