git - stash 后出现的 'WIP' 和 'index' 提交是什么？

Question

当我在本地开发分支上运行 git lg 时，最新的提交如下所示:

* 7d21213 - (1 hours ago) update business rules - developer1 (HEAD, origin/develop, origin/HEAD, develop)

但是，如果我通过运行 git stash 来存储本地更改，然后运行 ​​git lg，我会得到以下信息:

*  at12334 - (13 seconds ago) WIP on develop: 7d21213 update business rules - developer1 (refs/stash)
|\
| * ef9a11b - (14 seconds ago) index on develop: 7d21213 update business rules - developer1
|/
* 7d21213 - (1 hours ago) update business rules - developer1 (HEAD, origin/develop, origin/HEAD, develop)

这是什么意思？似乎在存储后创建了两个新提交(标记为 index 和 WIP)。是这样吗？如果是这样，此类提交背后的逻辑是什么？

---

注意事项

git lg

是已经在测试环境中定义的别名

git log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)' --all

Answer 1

“WIP”是 Work-In-Progress 的缩写。它的意思是建议您暂时保存当前的工作状态，即使您不在自然停止点也是如此。

Stashing 使用熟悉的提交/merge 机制将您的工作保存在存储库中。特别是，可以通过运行 gitk --reflog 在上下文中查看所有当前 stash 的项目，尽管只有最近的 stash 将被标记为 stash。常规提交和存储之间的一个重要区别是，当删除存储时(例如通过 git stash clear)，它们在 reflog 中不再可见，因此将更难以恢复。

存储通常分为两部分:

1. 对自上次提交以来“添加”的任何内容执行“索引”提交。
2. “WIP”提交作为工作状态和索引提交之间的 merge 执行。

如果自上次提交以来您没有执行任何add 操作，则索引提交将为空。但是，即使索引为空，它仍然会被提交。 The subsequent implicit merge can complicate things，例如，如果您想要从存储中挑选，以避免与 git stash pop 相关的某些复杂情况。

---

Git 的存储机制很聪明， powerful ，而且很有用，但它也很复杂，容易出错，而且很危险。我最近的做法是避免使用 git stash 来获得类似的结果，比如 git commit -a -m "stash" 来保存我的工作和 git reset HEAD~1 (在 checkout “stash ”提交之后)恢复它。

这留下了 git stash 最有用的应用程序，它只是在您知道您不再需要它们时摆脱所有本地更改的快速方法。

顺便说一句，您可以通过运行 git stash clear 从日志中删除“WIP”和“index”提交——但是如果您有有值(value)的工作，请不要这样做仅保存在 stash 。