Question

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

我目前的做法（见下面的摘录）：

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

我的问题：

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

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

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

以下是我当前方法的相关摘录：

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为开发人员提供快照以恢复到例如如果他们失去了提交腐败的项目。这将导致大量的微小提交，几乎没有个人价值，这没关系 - 事实上，它是我的需求的理想选择。

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

Answer 1

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

git stash apply

autocommit可能会产生需要手动解决的冲突。这将从整个过程中“自动”。
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

<强>解释

保存工作副本的当前状态。
带回工作副本。
舞台上的一切
在当前分支上进行虚拟提交。这将被复制到`autocommit'，然后从当前分支中删除。
将autocommit与我们的更改合并，以便于移动更改。 ours策略确保合并的结果与我们要保存的工作副本的状态相同。永远不会与此策略发生合并冲突。此合并无法在autocommit中完成，因为没有theirs策略。
转到autocommit分支。
将更改带入分支。 --squash选项至关重要。没有提交，而是所有更改都已暂存。
提交分阶段更改。
回去。
删除虚拟提交和合并提交。
返回原始状态。

结果应该是autocommit上代表工作副本的单个提交。

请注意，此脚本可能会提交大量垃圾（构建文件）。 autocommit分支对于不同的开发人员也将是非常不同的。我建议它仍然是本地的，以避免膨胀原来的回购。如果必须推送它，请尝试为每个开发人员提供自己的分支名称以避免冲突。

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

我目前的做法（见下面的摘录）：

我的问题：

偏离git哲学

1 个答案: