使用已提交的未跟踪文件应用存储

Question

我被要求编写一个脚本以在 Visual Studio 的构建后事件中运行，该脚本将通过将所有更改（包括新的（未跟踪的）文件）提交到本地“自动提交”分支来响应输出更新构建.这个想法是为了帮助懒惰的开发人员经常备份可构建代码，这样他们就可以避免丢失他们的工作。

我目前的做法（见下面的 sn-p）：

如果用户不在自动提交分支上，我会存储他们的更改和未跟踪的文件，签出自动提交分支，应用存储，然后提交，然后返回到上一个分支并从存储中弹出以返回初始状态.

我的问题：

如果文件在用户当前分支上未跟踪，但已自动提交到自动提交分支，则git stash apply 无法用存储中未跟踪的版本覆盖自动提交分支上跟踪的文件。

从git stash documentation 看来，我似乎没有任何相关参数可以在apply 调用中使用来解决这个问题。我可以通过解析git status --porcelain 以?? 开头的行的结果，在存储之前检测当前分支中未跟踪的文件，但这不会告诉我哪些文件已经在自动提交分支上被跟踪。

我目前需要使用 Windows 批处理文件，因此我想将我的解决方案限制在任何开发机器上可能在该环境中可用的工具上。

这是我当前方法中的相关 sn-p：

git stash save --include-untracked -keep-index
git checkout autocommit
git stash apply
git add -A
git commit -m "Autocommit of build %VERSION%"
git checkout  %BRANCHNAME%
git stash pop

偏离 git 哲学

自动提交过程旨在严格用作一个方便的、基于 git 的自动保存系统，它不需要开发人员在每次成功重建项目时触摸 git 或采取任何额外的手动步骤。

它不符合普通的 git 哲学，因为它不打算用于源代码控制或代码共享。我只是想使用 git 为开发人员提供快照以恢复到例如如果他们因文件损坏而失去项目。这将导致大量微小的提交而没有什么个人价值，这没关系 - 事实上，它非常适合我的需求。

脚本假定当前分支上未提交的更改可以合理地应用并提交到自动提交分支。假设无效的任何原因都将由开发人员与 repo 的直接交互引起。作为任何此类交互的一部分，开发人员负责相应地更新自动提交分支，以便脚本的假设在下次运行时有效。

Answer 1

我发现您的方法存在一些潜在问题：

1. git stash apply on autocommit 可能会产生需要手动解决的冲突。这将把“自动”排除在整个过程之外。
2. autocommit 上的提交不能保证与当前工作副本相同，因为git stash apply 执行合并。

以下顺序应该可以解决这些问题并回避您的原始问题。

git stash -u
git stash apply
git add -A
git commit -m "dummy"
git merge --no-ff autocommit -s ours
git checkout autocommit
git merge - --squash
git commit -m "Autocommit of build %VERSION%"
git checkout -
git reset --hard HEAD~2
git stash pop

说明：

1. 保存工作副本的当前状态。
2. 恢复工作副本。
3. 上演一切
4. 在当前分支上进行虚拟提交。这将被复制到“自动提交”并随后从当前分支中删除。
5. 将autocommit 与我们的更改合并，以方便移动更改。 ours 策略确保合并的结果与我们要保存的工作副本的状态相同。与此策略永远不会发生合并冲突。此合并无法在autocommit 中完成，因为没有theirs 策略。
6. 移至autocommit 分支。
7. 将更改带入分支。 --squash 选项至关重要。没有提交，而是暂存所有更改。
8. 提交分阶段的更改。
9. 后退。
10. 删除虚拟提交和合并提交。
11. 返回原始状态。

结果应该是在 autocommit 上的一次提交，代表工作副本。

请注意，此脚本可能会提交大量垃圾（构建文件）。 autocommit 分支对于不同的开发人员也会有很大的不同。我建议它保持本地化以避免使原始存储库膨胀。如果您必须推送它，请尝试为每个开发人员提供自己的分支名称以避免冲突。