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

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

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

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

分支似乎对此有些杀伤力。我们如何在环境中进行操作以隔离测试构建和发布的更改？

@Matt b：因此，当我们等待有关更改的反馈时，我们会怎么做？我们是否总是在做一件事？

解决方案

回答

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

对于特定示例，我将在启动任务ABC之前签出源的干净副本，并在实施ABC之后在其中创建本地构建。

回答

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

回答

因此，我们在问如何一次处理多个"任务"，对吗？除了分支。

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

在一个工作副本/提交中混合多个任务可能会造成混乱，特别是如果有人以后需要查看工作时。

回答

我尽力使每个"提交"操作代表一个单一的，有凝聚力的变化。有时，它是一个完整的错误修复程序或者一个完整的功能，有时是在实现更大功能的过程中进行的一次小型重构。没有一种简单的方法可以凭直觉来决定这里的单位。我也要求(乞求！)我的队友也这样做。

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

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

这样的工作可以减少对小分支的需求，因为我们可以采取自信的小步骤，对其进行验证并提交，然后重复进行。我已经讨论过如何使步骤小而自信，但是要使此步骤有效，我们还需要使验证阶段快速进行。具有快速，细粒度的单元测试和高质量，快速的应用程序测试的强大功能是关键。

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

尽管如此，我的大脑似乎仍然喜欢繁重的多任务处理。为了使该工作正常进行，我仍然希望进行多个正在进行的更改。我使用了多个分支，多个本地副本，多台计算机和工具来备份未决的更改。他们都可以工作。 (并且所有这些都是等效的，并且以不同的方式实现。)我认为，多个分支是我的最爱，尽管我们需要一个源代码控制系统，该系统应能够轻松快捷地扩展新分支，而又不会给服务器造成负担。我听说BitKeeper擅长于此，但我还没有机会进行检查。