git隐藏修改
我最近发现自己经常使用一种模式,我一直将其称为“ git stash驱动的开发” –也就是说,在我的开发工作流程中,很大程度上依赖git stash的魔力。
通常,我遵循我认为是相当典型的TDD工作流程的方式:
- 编写下一个测试,看它失败
- 编写代码以使其通过
- 承诺
- 重构
- 承诺
- 推
此周期可以非常频繁地重复-每隔几分钟重复一次。 有时,在下一个要编写的测试不明显或重构需要更多考虑时,此周期会变慢。 但这通常是我尝试并遵循的过程。
我经常写下一个测试,这使我对自己的功能有所了解,但遇到了一个问题:我实际上无法(轻松地)使测试通过。 首先,我需要重构以使问题变得容易。 在这种情况下,我可以将测试标记为已忽略,然后提交并稍后再返回。 我根据需要重构,提交,推送; 然后终于忽略了我的测试,回到了以前。 这是一个相当整洁的过程。
但是,有几次该过程无法正常工作:如果我在编写测试过程中遇到了一部分,但我意识到不重构测试基础架构就无法完成? 我不能忽略我的测试,它甚至可能没有编译。 我当然不想在当前状态下提交它。 如果遵循15分钟的规则,我可以将我的测试装箱并重新编写,不会失去太多工作。 但是,借助git stash的魔力,我可以存储所做的更改,并在重构测试代码后返回。
当我正处于重构步骤的过程中时,这种情况会更令人讨厌。 当我真正进行设计更改时,这种情况会更常见-并不是真正的重构,因为它经常发生在正常的TDD循环之外。 我正在尝试将设计扩展到其他地方。 有时,这是由测试驱动的,有时是非功能性的重构。 但是,经常在许多源文件中发生不重要的变化。 在这一点上,很容易获得重构的一部分,并意识到需要先发生其他事情。 我可以整理我的零钱,我只会失去15分钟的工作-但是当我有git stash时为什么要扔掉它呢?
因此,我git存储了我的更改,然后进行需要首先进行的更改。 然后,很常见的是,我在第二个更改中有所作为,并意识到首先需要进行其他操作。 好吧,git再次藏起来! 如果您不小心的话,这堆git存放的内容可能会变得很深。 但是,一旦我将堆栈底部降至最低,一旦我设法提交一个重构以释放上面的步骤,我就可以git stash pop,完成下一个重构,提交,git stash pop。 等等,直到完成为止。
现在,可以争论的是,我发现反向重构,但是在我看来,这常常是我找到它的方式。 当然,我本可以花更多时间详细分析更改。 在按照正确的顺序进行整理之前,请花时间计划我的纸上更改。 但是,这总是很耗时,并且仍然存在我错过某些东西并进行“后退”更改的风险。 我发现以这种方式使用git stash可以使我发现一次需要执行一个步骤的重构。 每次提交都保持较小,我尝试遵守15分钟的规则,以使单个提交不会丢失超过15分钟的时间。 最终,设计更改将通过一系列小的提交来完成,每个提交都在逻辑上基于之前的提交。 它们是通过探索发现的,而提交只是以相反的顺序被发现的。
危险始终是我找到了无法按照我想象的方式完成的重构步骤–现在我无法展开堆栈,并且可能所有以前的git存放区都无法提交。 每当发生这种情况时,我通常会发现堆栈上移一到两个级别将呈现一种不同的方法,从这里我可以像以前一样继续。
翻译自: https://www.javacodegeeks.com/2016/01/git-stash-driven-development.html
git隐藏修改