【发布时间】：2021-11-12 00:01:55
【问题描述】：
假设场景，我修改了两个源文件，但只暂存其中一个，并执行提交（本地）这个特定的提交将代表文件系统中不存在的源状态，所以我无法测试是否它是否编译。 （这是提交策略所必需的）
在本地恢复到该特定提交（然后编译）将导致未暂存文件的更改丢失。 如果不将其推送到远程，我无法将其克隆到其他文件夹以测试是否编译，但是将其推送到远程将使未经验证的源可供团队使用，所以让事情变得更糟。
我能找到的唯一工作流程是，创建当前源的本地（备份）副本，然后将本地存储库恢复为提交，（接受丢失的未提交更改（未暂存的源文件）），编译，如果没有编译，则从备份中复制回来，修改，猜测，修改，仍然没有暂存我最初不想提交的内容，然后重复此循环直到恢复文件正在编译。
问题
这听起来太复杂了，要么
- a) 我想念一些东西，
- b) 暂存需要彼此严格一致的文件（源文件），暂存不是一种可用的做法。对多个文件的修改必须是原子的（a la ACID）。
【问题讨论】：
-
进行尽可能多的 本地提交，即使它们没有构建 - 唯一重要的是您的代码构建在 压缩提交 将从您最终提交的 PR 中合并。
-
您误解了提交策略的性质：它们（旨在）仅用于来自功能分支的合并提交。提交政策不与您的本地提交有关（否则任何人将如何完成任何事情？）
-
……也就是说，你为什么不压缩/追加/重新定位？
-
确实，本地提交不会破坏其他人的工作，但是它仍然存在，甚至进一步的提交将被编译，远程仓库仍然会被不可用的不编译提交污染。不暂存文件的目的是什么，在一系列 local 提交期间保留该文件更改，然后最终在提交中发布它，然后将所有提交推送到远程？如果整个都在本地，那么整个不登台并保留一些更改以查看其他人变得毫无意义。此外，必须编译是每次推送的提交都必须进行的，除了在私有分支中。
-
“远程仓库仍然会被不可用的不编译提交污染”——这就是我说压缩提交的原因。