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

Question

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

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

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

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

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

@Matt b：所以当你等待改变的反馈时，你会怎么做？你总是在做一件事吗？

Answer 1

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

您可以在本地计算机上对源进行多次检出，并在目录名后面加上您正在处理的故障单的名称。只需确保在正确的目录中进行更改，具体取决于任务......

在一个工作副本/提交中混合多个任务可能会非常混乱，特别是如果有人需要稍后审核您的工作。

Answer 2

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

对于您的具体示例，我会在启动任务ABC之前检出源的干净副本，并且在实现ABC之后，在其中创建一个本地构建版本。

Answer 3

类似的东西：git stash＆amp;＆amp; ./bootstrap.sh& amp;＆amp;做测试:)）

Answer 4

我努力使每个“提交”操作代表一个单一的，有凝聚力的变化。有时它是一个完整的错误修复或整个功能，有时它是一个小的重构在通往更大的东西的路上。没有简单的方法来决定一个单位在这里，只是通过直觉。我也请求（乞求！）我的队友也这样做。

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

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

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

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

然而，我的大脑似乎喜欢沉重的多任务处理。为了实现这一目标，我仍然希望进行多项正在进行的更改。我使用了多个分支，多个本地副本，多台计算机和tools that make backups of pending changes。他们都可以工作。 （并且所有这些都是等效的，以不同的方式实现。）我认为多个分支是我的最爱，尽管你需要一个能够快速启动新分支的源代码控制系统。轻松，不会成为服务器的负担。我听说BitKeeper很擅长这个，但我还没有机会查看它。