背景：让我们考虑两个分支“验证”和“开发” 我做了一些关于开发，提交和推送它们的编码。然后我切换到验证来编写一些修复程序。这些必须不包括开发最后一次提交，所以我以任何方式避免任何合并，只是检查出来。
编码修复后，我拉动同事工作，没有冲突，我推。而bam，昨天开发的代码已合并。我不知道为什么，我需要知道为什么要再次犯这个错误。
以下是我今天的命令列表：
> git status
On branch validation
Your branch is up-to-date with 'origin/validation'.
nothing to commit, working tree clean
此时我编写了修复代码。然后我拉同事工作来检查冲突。
> git pull
remote: Counting objects: 81, done.
remote: Compressing objects: 100% (59/59), done.
remote: Total 81 (delta 59), reused 38 (delta 22)
Unpacking objects: 100% (81/81), done.
From http://url-repository/project
659ae17..d32944f branchC -> origin/branchC
dcabc87..9d7c53e branchR -> origin/branchR
e58e529..64ac92f develop -> origin/develop
Already up-to-date.
> git fetch =＆GT;什么都没有显示
> git add . =＆gt;什么都没有显示
> git commit -m "commit comment"
[validation 88341a6] commit comment
X files changed, Y insertions(+), Z deletions(-)
create mode 100644 path/to/filemodified
此提交包含我在develop分支上进行的编辑。为什么？
我们注意到了这个错误，自从犯罪提交以来已经做了很多工作，回滚不是一个选项（我甚至不知道这是否可能）。我只需要了解原因。
答案 0 :(得分：0)
git push永远不会合并。
git pull字面意思是：运行git fetch，然后运行git merge。后者有时会合并。但是，您显示的输出表明没有任何内容可以合并。
我认为发生的事情要简单得多：你在这里犯了错误的分支（并且工作过）。如果是这样，可能有一个简单的解决方法：检查正确的分支，使用git cherry-pick将错误的提交复制到正确的分支，并git branch -f validation origin/validation重新调整旧的validation分支与origin/validation匹配（假设您尚未将validation推送到origin）。
（使用git cherry-pick复制提交意味着：通过将指定的提交快照与其父快照进行比较，将给定提交转换为更改集。然后应用此更改 - 设置当前分支上的当前提交，从结果中进行新提交。）
让我们逐行采取这些措施：
> git status On branch validation
这意味着，当您运行此git status时，您当前的分支是（或曾经）validation。
Your branch is up-to-date with 'origin/validation'.
这意味着您当前分支机构的上游设置为origin/validation，并且您的两个名称origin/validation和validation都会识别现在同一次提交（截至您运行git status时）。
nothing to commit, working tree clean
这意味着您的索引与您当前的提交相匹配，您的工作树（又名＆＃34;工作树＆＃34;）与您的索引匹配。
您的索引始终包含文件快照：如果您现在正在创建，则这是将进入您提交的新提交的快照。如果该快照与当前提交下保存的快照相匹配，Git会说没有什么可以提交，有时声称这意味着它的空白＆＃34 ;，但索引实际上一直都是文件。通常，当您git checkout otherbranch时，Git 替换索引内容，将其从＆＃34;当前分支的当前提交中的所有内容更改为＆＃34;使用＆＃34;提示otherbranch＆＃34;中的所有内容。它也以相同的方式替换工作树内容 - 然后将您更改为otherbranch，以便otherbranch 的提示提交当前提交，结账成功。这意味着索引继续匹配当前提交。
此时我编写了我的修复程序。
但结果是git add和git commit吗？如果是这样，git add将更新的文件从工作树复制到索引中，git commit从索引中创建一个新的提交（已经存在的所有未更新的文件，再加上新的来自git add的更新文件。新提交现在与索引匹配，我们回到那个＆＃34;每个人都很高兴＆＃34;当前提交以及索引和工作树都匹配的模式。
请注意，当前分支名为validation，因此如果您执行 git commit，则会更改名称validation指向的提交，以便它指向刚刚提交的新提交。
如果您没有添加和提交任何内容，则更改的文件现在位于工作树中，但不在其他地方。这是一种不太开心的模式，因为您更改的文件尚未永久保存在某处。提交（主要）是永久性的，并且（完全）只读，因此一旦提交，这些更新的文件将被快照，从而永久保存 - 或者至少保存，直到您和其他人停止使用提交，如果发生的话。 / p>
我认为情况就是这样，你还没有运行git add和git commit。
然后我拉同事工作以检查冲突。
git pull
此git pull运行了fetch，其中打印了：
remote: Counting objects: 81, done. remote: Compressing objects: 100% (59/59), done. remote: Total 81 (delta 59), reused 38 (delta 22) Unpacking objects: 100% (81/81), done. From http://url-repository/project 659ae17..d32944f branchC -> origin/branchC dcabc87..9d7c53e branchR -> origin/branchR e58e529..64ac92f develop -> origin/develop
以remote:开头的行只是Git从其他Git（origin转发的信息）转发的信息，它只是评论它如何收集要发送给您的对象Git，尽可能地缩小它们以便通过慢速网络。 Unpacking objects行是你的Git评论它为将它们再次分开所做的工作。最后四行是你的Git告诉你它是如何记录它从其他Git获得的新信息：
branchC曾经指向提交659ae17，这是您的Git最后一次使用他们的Git检查，但现在指向提交d32944f。您的Git以您的名字origin/branchC保存该内容。branchR曾经指向dcabc87但现在是9d7c53e，而您的Git正在以您的名字origin/branchR保存该内容。develop为e58e529，现在为64ac92f，您的Git正在origin/develop下保存。{/ li>
然后，这个git pull运行git merge，打印出来：
Already up-to-date.
由于您位于validation分支上，并且git fetch未更新origin/validation分行的validation内存，因此git merge已制作没有任何改变，也没有任何新的提交。您仍然在validation分支上，包含工作树中的任何文件，以及索引中的任何内容，仍然在索引中。
> git fetch=＆gt;没有显示
这并不奇怪，因为git pull刚刚运行git fetch。你的第二个git fetch再次在origin调用了另一个Git，但是自从之前的调用以来没有任何改变那里，因此没有任何对象打包和发送，并且没有更改name-to-commit-hash值以使您的Git更新远程跟踪origin/*名称。
请注意，您仍然在validation分支机构。
> git add .=＆gt;没有显示
git add命令通常是静默的，因此无论Git是否将工作树中的文件复制到索引中，这都是正常的。但是，当它完成后，您的索引内容现在与您的工作树内容相匹配（工作树中的文件除外（1）不在索引中，（2）列在{{1文件或其他类似的排除文件）。换句话说，您的索引现在都已设置为进行新提交。
.gitignore
而且，如果我没有> git commit -m "commit comment"
[validation 88341a6] commit comment
X files changed, Y insertions(+), Z deletions(-)
create mode 100644 path/to/filemodified
- ed和git add - 编辑任何东西，那么你现在在自己的git commit分支上进行了提交。你想到你在validation分支机构，但你显然不是：develop如此早说，而git status刚刚说过。< / p>