使用 git 和工作流程，其中我有许多不适合 checkin 的松散更改。有没有一个好的git方法来管理那些不可 checkin 的修改文件？
在我的项目中，我们有大约 700,000 个源文件。我将其称为一个更大的项目。
当我致力于修复错误或实现功能时，我经常会得到许多已进行辅助编辑的文件。例如调试仪器，或替代实现，或对从未发生过的情况进行昂贵的检查，这种情况曾经似乎在野外发生过，并且我想在我的机器上发生过这种情况时捕获它，或者clang-format 因为原来的格式很愚蠢。
为了提交我的良好更改，我将进行分支，我仔细添加相关文件并提交这些文件。 (接下来是推送我的更改。制作 PR。获得代码审查批准。Jenkins 在所有十几个不同的目标平台上构建，并运行测试套件。然后我将我的分支 merge 到主分支中。)
可能是一个相当典型的工作流程...除了我有许多(1000+)非 checkin 文件，我想在工作树中保留这些文件的修改，但不将它们 merge 到主文件中。后一部分可能是非典型的。
使用 Perforce，我会将不需要 checkin 的文件添加到不需要 checkin 的更改列表中，并将它们 stash 在那里。它们不会妨碍我，而且如果不采取措施将其从不可 checkin 的更改列表中移出，我就不会意外地 pull 出其中一个“受污染”的文件。
到目前为止，我的 git super 小心的策略已经奏效，但似乎充满了危险。我维护一个 stash.txt 文件，其中包含我的非 checkin 文件列表，并且经常stash 它们以暂时将它们移开，执行以下操作我的 git 东西(创建分支、获取、 merge 、推送等等)，然后将它们 stash 到我的工作树中。看起来很笨拙、手动且容易出错；高认知负荷。必须有更好的方法。
(当我有一个文件同时具有良好的更改和不可 checkin 的更改时，我还没有遇到过这种情况。如果/当我这样做时，我知道如何添加并提交大块变化。)
我尝试过创建分支的策略，添加并提交我的好的更改和不 checkin 的更改。然后挑选出应该放入 main 的好的更改。对于需要筛选的 1000 个非 checkin 文件来说，这种方法的扩展性很差。
感谢任何建议或指导。
最佳答案
框架挑战:这不是 git 问题，而是应用程序架构问题。
在工作树中留下大量未提交的更改意味着:
- 它们可能没有在任何地方备份；如果你的开发机器明天出现故障，你将失去所有你一直小心保存的工作
- 除了你之外，没有人能从他们那里受益；您的同事很可能正在浪费时间再次进行相同的更改
- 您正在开发的应用程序版本逐渐偏离实际部署到生产环境的版本
让我们看看您提到的示例更改:
- 调试工具 - 将其提交到“仅开发模式”标志、一组调试功能标志后面，或者改进您的调试工具，这样就没有必要了(例如，当您有一个工作交互式调试器)
- 替代实现 - 应在其自己的分支上，直到准备就绪；或者在“原型(prototype)”功能标志后面提交，以便您可以将其关闭以重现实时行为
- 对从未发生过的情况进行一次昂贵的检查，这种情况曾经似乎在野外发生过，如果它发生在我的机器上，我想捕获它 - 再次，这是功能标志的理想用途
- clang-format 因为原始格式有愚蠢的格式 - 只要提交它，从长远来看每个人都会感谢你
关于Git 工作流程中有许多修改过的文件不适合 checkin ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/69928486/