当我的工作树和/或索引很脏时“git pull”是否安全？答案

【问题标题】：Is it safe to "git pull" when my working tree and/or index is dirty?当我的工作树和/或索引很脏时“git pull”是否安全？
【发布时间】：2012-04-09 00:02:12
【问题描述】：

假设我有一个 git repo，其工作树和/或索引是“脏的”（即我有尚未提交或隐藏的本地修改）并且我很想在没有先提交的情况下执行“git pull”或藏匿。（或者，假设我正在向 git 介绍一个新的团队成员，他们当他们的本地仓库“脏”时很想运行“git pull”。）我'我想知道在这种情况下执行“git pull”有多安全。如果不安全，可能发生的最糟糕的事情是什么？我是从受信任的来源还是从不受信任的来源中提取内容有关系吗？

到目前为止，我的调查提出了一系列令人困惑的想法，我认为这是一个相当简单的问题。

首先，git-stash 手册页让 git pull 听起来非常安全，如果您处于可能出现问题的情况下，它会中止：

   Pulling into a dirty tree
       When you are in the middle of something, you learn that there are
       upstream changes that are possibly relevant to what you are doing.
       When your local changes do not conflict with the changes in the
       upstream, a simple git pull will let you move forward.

       However, there are cases in which your local changes do conflict
       with the upstream changes, and git pull refuses to overwrite your
       changes. In such a case, you can stash your changes away, perform a
       pull, and then unstash, like this...

到目前为止，在我的简单测试中，这似乎也发生了。

也可能暗示“git pull”非常安全，Visual Studio 的Git Extensions 工具栏有一个显眼的拉动按钮，它在向“git pull”发射之前不会检查是否脏污。（如果我正在设计一个 Visual Studio 工具栏，我会尽量避免让自己特别容易被人踩到脚。）

git-pull 手册页不会让我的“git pull”听起来很危险，尽管它表明这不是最佳实践：

   If any of the remote changes overlap with local uncommitted changes,
   the merge will be automatically cancelled and the work tree untouched.
   It is generally best to get any local changes in working order before
   pulling or stash them away with git-stash(1).

但是你也可以找到建议，拉入肮脏是非常糟糕的，e.g.：

Avoid git-pull!
git-pull should never get invoked if you have dirty files lying around or if your branch is ahead of master.
This will always lead to some dirty artifacts in the commit history

对于哪种观点最好有一个简单的答案，或者这是否是一个个案？

跟进：使用“git pull --rebase”而不仅仅是“git pull”会改变答案吗？在某些情况下，rebase 可能有它的 own pitfalls，但到目前为止，我的猜测是，拥有一个肮脏的工作树/索引不会使 rebase 比其他情况更成问题。

【问题讨论】：

标签： git git-pull

【解决方案1】：

对维护 Apache DeltaSpike 项目的人没有冒犯，但我相信 Git 手册页对 Git 的评价，而不是 Delta Spike wiki 的内容。

还要注意在引用的文本中（强调我的）：

git-pull 不应该被调用，如果你有脏文件在或者你的分支在master之前。这总是会导致提交历史中出现一些脏工件。

“提交历史中的脏东西”是 Git 合并提交。每当您合并分支而不是将一个分支的内容重新基于另一个分支时，都会发生这种情况。这些合并提交是否“脏”取决于您的项目、您的组织及其意见和政策。

无论如何，git-pull 绝不是危险的操作。如文件所述，它不会破坏您的任何历史记录或正在进行的工作。

【讨论】：

来自 wiki 的声明很奇怪：本地修改永远不会导致提交历史中出现“工件”。
@Jefromi：确实。这就是为什么我把重点放在后面的部分（如果需要，它会自动创建提交）。
我在 DeltaSpike 的 Wiki 中看不到这样的评论。
@DarWhi：link in the question 包含第一部分中的注释，标题为“避免 git-pull！”。链接标题文本仅为“例如”所以它相当微妙。
@DarWhi：你只是在重新表述我在帖子和我的 cmets 中所说的话。

【解决方案2】：

根据我的经验，它绝对安全（我使用 git 大约 4 年）。如果您有未提交的更改，它通常不会告诉您您有一个脏工作副本。

【讨论】：

【解决方案3】：

git pull 只是 git fetch + rebase/merge，自动合并会产生噪音或意外结果。（噪音示例：当您所做的只是将一行添加到同一个文件 10 次时，您不需要 10 次合并提交。）如果初学者只是简单地执行 git pull 并在没有检查，噪音将被检查。

我只想说，新团队成员在 git pull 在脏工作树上之后更有可能迷失方向，是否安全，这将取决于响应（每次拉取后检查结果将是一个好的开始）。

【讨论】：

【解决方案4】：

到目前为止，我不确定这是否真的与 git pull 相关（这听起来像是预先检测到是否可能存在合并冲突并在可能的情况下中止），但至少要注意 merging （即进行 git 合并）到脏工作树中显然会限制您在合并失败的情况下“撤消”合并的能力。特别是，来自 git-merge 手册页：

   [merge] --abort
       Abort the current conflict resolution process, and try to
       reconstruct the pre-merge state.

       If there were uncommitted worktree changes present when the merge
       started, git merge --abort will in some cases be unable to
       reconstruct these changes. It is therefore recommended to always
       commit or stash your changes before running git merge.

【讨论】：

【解决方案5】：

场景 A：

如果 拉取的提交 会与 工作树中未提交的更改 发生冲突，那么 Git 将中止并避免您将代码库弄得一团糟。

场景 B：

如果 拉取的提交 会与 您的仓库中已提交的更改 冲突，并且您也有 您的工作树中未提交的更改 不会发生冲突，那么你最终会手上一团糟。您必须解决冲突并提交，而不会忘记拉取之前工作树中的更改。

在将新的团队成员介绍给 Git 之后，我有时会遇到场景 B。我团队的新成员的一个常见错误是意外/疏忽地更改了我们网络驱动器存储库中的文件，而不是他们应该做的本地克隆文件，而且他们也忘记提交这些更改！

顺便说一句，保护自己免受团队错误影响的一种方法是始终首先拉取干净的本地存储库，在本地处理任何冲突，然后从本地存储库拉取到与团队共享的存储库.这个额外的步骤可以防止出现场景 B，或者让脏树对您透明，或者在最坏的情况下，为您呈现场景 A。幸运的是，场景 A 可以作为正常冲突处理，而不会像场景 B 那样令人头疼。

【讨论】：

【解决方案6】：

git fetch

然后根据从服务器获取的内容进行合并、变基或重置。您可以使用拉动，它不会破坏正在进行的工作。但首选前一种方法。

【讨论】：