大多数情况下,在做一些工作时,最终会有更改应保存到不同的提交中.
我正在寻找如何以良好的方式做到这一点的最佳实践.
当然,基本的答案是使用git add -p.
该基本答案的问题在于它无法在提交之前测试存储库的给定状态.通常,这意味着忘记添加一些导入,或忘记某些分阶段代码和一些非分段部分之间的依赖关系.因此,给定的提交不会传递构建.
因此,我正在寻找一种方法来创建几个提交,能够为每个提交运行测试.
到目前为止我尝试过的工作流程如下:
工作流程1:提交,存储然后测试
只要有超过1次提交与当前更改,重复:
> git add -N< new files> #将所有新文件标记为可分阶段
> git add -p#仅添加第一个提交的更改
> git commit
> git stash save -k -u
>运行测试
>虽然测试没有通过
> git stash pop
>修复代码
> git添加相关更改
> git commit –amend –no-edit
> git stash save -k -u
> git stash pop
我在这个工作流程中看到的主要问题是这样一个事实,即在没有经过测试的情况下提交一些东西没有多大意义,因为它知道很快就会被修改.
工作流程2:存储,测试然后提交
只要有超过1次提交与当前更改,重复:
> git add -N< new files> #将所有新文件标记为可分阶段
> git add -p#仅添加第一个提交的更改
> git stash save -k -u#删除未添加的所有内容
>运行测试
>虽然测试没有通过
> git stash pop
>修复代码
> git添加相关更改
> git stash save -k -u
> git commit
> git stash pop
我发现该工作流程的主要问题是git stash pop经常因冲突而失败.这导致必须在所有冲突文件上重做git add -p,这可能非常耗时.当尝试仅添加新文件的一部分时,会发生这种情况.
这个问题
在测试每个提交时是否还有其他更好的实践可以保存到多个提交中?
最佳答案 忘记藏匿,使用交互式rebase.根据需要提交所有内容并在以后清理混乱.
我建议使用git gui来创建提交,但这是一个小问题.过了一会儿,我得到了一份提交列表
Implement feature A
Refactor mess B
f A 1
f A 2
f B 3
Improve formatting
f A 4
f B 5
其中“f A”表示“修正A”.然后我打电话
git rebase -i
或者可能
git rebase -i HEAD~8
获取提交列表并重新排序
Improve formatting
Implement feature A
f A 1
f A 2
f A 4
Refactor mess B
f B 3
f B 5
我在很多小步骤中重新排序,以防它失败.我使用git diff ORIG_HEAD来验证最终版本是否保持不变.
作为最后一步,我将“pick”更改为“f”(fixup),这样我最终只能进行三次提交.
要在中间步骤上运行测试,您还可以使用rebase.只需将“pick”替换为“e”(编辑),以便git在每次提交后停止(使用git rebase – 继续继续下一次提交).
在进行这样的提交清理时,我通常会在最后通过时运行测试,如果不这样做,修复通常很明显.
在重新定位时,请注意不要更改推送到共享存储库的提交.