合并冲突期间，'git pull'将其他人的承诺带入我的集结区 [英] 'git pull' brings others' commits into my staging area during merge conflict
问题描述
每当我有一些本地提交时，我做了一个 git pull ，git将所有其他人的提交到我的暂存区，以防合并冲突。现在，尽管冲突在一个文件中，但我不明白为什么git会将其他人的非冲突提交带入我的暂存区域，要求我将它们提交，就好像它们是我所做的更改/提交一样。
最近，我在同事的笔记本电脑上出现了同样的行为，我们在提交之前取消了未由同事添加的所有文件，然后提交了唯一有冲突的文件。而发生了什么，是非常意外的。 Git显然删除了所有这些文件，并没有解决所有的变化，就好像我们的提交扭转了它们。然而，最奇怪的是，我们查看了Stash（我们使用Stash来管理中央回购），而且我没有看到我们的这些文件被撤消在Stash中提交。
我很茫然，因为这是如何发生的。任何似是而非的解释？另外，我看到Stash有时很奇怪。这似乎不可靠。它不会在两次提交之间显示任何更改，但有时会发生更改。我不知道这是怎么发生的，但是是否有其他人遇到过这些问题？
更新：我后来意识到这一点Stash并不奇怪只是有点不直观。合并时，它显示基于两个不同父母的变化。还有一个小小的下拉菜单，可以让您更改父级以查看与其相对应的更改。我认为在这里更新它会很好，所以人们不会有误导性的想法。 解决方案
上一次将本地分支与远程分支同步之间的所有更改的结果
Git pull自上次拉取之后'取得'了更改，然后它会尝试将远程分支的本地副本合并到本地分支中。然后它在其中一个已更改的文件中发生冲突。
因此，它必须在合并过程中停下来询问如何将冲突解决为一个文件。
所以其他文件已经准备好合并，已经上演，如果没有其他冲突，它们会自动合并。
要完成自动合并，您需要a）解决冲突，然后b）点击提交以完成将其他人的更改合并到您的本地分支。 （一些GUI在你点击我已经完成解析按钮后自动完成提交步骤）
您还会注意到在GUI的提交窗口中，为未决的提交预先编制的合并消息？它会像将原点/ x合并到x ...冲突：y中那样。一旦所有更改的文件都可以添加到舞台上，您就可以完成暂停的自动提交。
所以这听起来像是我预期的行为，但是您只是看到内部的一个git的内部进程。
这里不需要存储。尽管有些图形用户界面会自动隐藏，但git本身并不会在使用隐藏过程中使用隐藏。
注意：当您执行pull操作时，本地不应该有任何已更改的文件。 （即在执行任何分支操作之前提交一切清理，这是一个不错的最佳实践）使用GUI清理已更改的文件是自动存储有用时的情况，但在存在冲突时仍然有其复杂性。即您需要解决冲突，然后记住随后弹出存储。如果你依赖过多的自动化，当你必须完成你不知道的自动化过程时，它会变得混乱！所以我建议你始终保持工作目录清洁。
So, I have faced this nasty problem quite often, and tried looking for any solutions online, but I am not sure if this is git's expected behavior or not.
Whenever I have a few local commits and I do a git pull, git brings all the other peoples' commits into my staging area in case, I have a merge conflict. Now, although the conflict is on a single file, I do not understand why git brings other peoples' non-conflicting commits into my staging area, asking me to commit them as if they were changes/ commits made by me.
Recently, I had this same behavior on a colleague's laptop, and we unstaged all the files not added by the colleague before committing, and then committed the only file that was conflicting. And what happened, was quite unexpected. Git apparently deleted all those files, undid all the changes, as if our commit reversed them.
However, the strangest thing of all was, we looked in Stash (we use Stash for managing the central repo), and I did not see those files being undone by our commit in Stash.
I am at a loss as how did this happen. Any plausible explanation? Also, I have seen Stash act very weirdly at times. It seems unreliable. It will not show any changes between two commits, and yet there are at times, changes. I have no idea how this happens, but has anyone else experienced these issues?
Update : I realized this later that Stash wasn't weird just a little unintuitive. When doing a merge, it showed changes based on two different parents. And there was a small dropdown that would let you change the parent to see changes corresponding to it. I thought it would be good to update it here so people do not have misleading ideas.
The staged files you are seeing are the results of all the changes between the last time you synchronised your local branch with the remote branch (I guess master as you do not mention it).
Git pull has 'fetched' the changes since you last pulled, then it tries to merge this local copy of the remote branch into your local branch. It then hit a conflict in one of the changed files.
So it has to stop in the middle of the merge to ask you how to resolve the conflict to the one file.
So the other files are ready to merge, have been staged and would have been merged automatically if there hadn't been any other conflicts.
To complete the automatic merge, you need to a) resolve the conflict then b) hit commit to finish merging the other people's changes into your local branch. (Some GUIs automate the commit completion step after you click a "I've finished resolving" button)
You will also notice in the commit window of your GUI, there is a pre-fabricated merge message for the pending commit? It will say something like "merging origin/x into x... Conflicts: y". Once all the changed files can be added to the stage you are ready to complete this automatic commit which was paused.
So this sounds like expected behaviour to me, but you are just seeing "inside" one of git's internal processes.
Stashing shouldn't be necessary or involved here. Although some GUIs do auto-stash, git itself doesn't use stashing during a pull.
Note: you shouldn't have any changed files locally when you do a pull. (i.e. commit everything clean before doing any branch operations, is a good best practice) Having a GUI clean up your changed files is when auto-stash is useful, but it still has its complications when there are conflicts. i.e. you need to resolve the conflicts then remember to pop the stash afterwards. If you rely on the automation too much, it gets confusing when you have to complete the automated process you don't know about! So I'd recommend always keeping your working directory clean.
这篇关于合并冲突期间，'git pull'将其他人的承诺带入我的集结区的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
