Git 合并母版将所有更改添加到我的分支

我在一家分公司工作，我更改了5个左右的文件。在这样做的同时，其他人将>100个文件中的更改推送到master。现在，在处理我的分支时，我想不时地在本地分支中合并master。我会这样做：

... <-F <-G <-H ...

...--G--H   <-- master, dev (HEAD)

          I
         /
...--G--H   <-- master, dev (HEAD)

          I--J
         /    \
...--G--H      M   <-- dev (HEAD)
         \    /
          K--L   <-- master

...--C--D--E   <-- branch1 (HEAD)
            \
             F--G--H   <-- branch2

git签出主机

git pull

git签出我的分行

git合并主机

git推送

---

但现在，由于某种原因，所有在master上被其他人更改的文件都被添加到我的更改中。因此，如果我真的在

合并主文件之后
推送
，它将显示我更改了>100个文件，而不是5个。我做错了什么？谢谢。
有两种git合并，
快进
和
无快进

您似乎遇到了
no fast-forward
类型，它将生成一个新的合并提交

如果不想生成合并提交，可以尝试使用git rebase

git checkout master  
git pull  
git rebase master my-branch （might encounter conflicts here）  
git push  

您可以找到动画
有两种git合并，
快进
和
无快进

您似乎遇到了
no fast-forward
类型，它将生成一个新的合并提交

如果不想生成合并提交，可以尝试使用git rebase

git checkout master  
git pull  
git rebase master my-branch （might encounter conflicts here）  
git push  

你可以找到动画
这里其实没有什么问题：你只是误解了Git所说的。（我想，Git可能被误解这一事实可能会被认为是一个问题，但在实践中，无论是Git还是其他版本控制系统，这一点都很难，需要学习和经验。）

关于Git、文件和提交，需要了解一些关键事项：


Git在与之交互的级别上存储的是提交。像
master
这样的分支名称很有用，但它们实际上只是帮助Git和您找到提交。稍后我们将看到这是如何工作的

提交确实存储文件，但您通常一次使用一个完整的提交。你告诉Git:GetMeCommitX，对于某个标识提交的X，你会得到该提交的所有文件。您要么拥有提交，因此拥有所有文件，要么根本没有提交，因此没有任何文件

每个提交都有一个唯一的ID。这个ID是它的散列ID，它是一个大而难看的随机字母和数字字符串，例如。该散列ID一旦存在，就意味着提交，而不是任何其他提交

任何一次提交的内容都是完全、完全、100%只读的。无论是保存在提交中的文件，还是提交的任何元数据，都无法更改。（原因是散列ID是提交内容的加密校验和。如果您取出一个提交，修改它的任何位，然后放回，您将得到一个新的、不同的提交，具有一个新的、不同的散列ID。旧的提交仍在其中：您刚刚添加了一个提交。）

每个提交的所有文件的快照就是：一个快照。也就是说，提交根本不存储更改

但当您查看提交时，Git通常会显示更改。这是个骗局！但这也是一件好事，因为这通常更有趣

Git可以将提交显示为更改的原因是，大多数提交都存储单个先前提交或父提交的原始哈希ID。因此，给定任何一个提交X，Git都可以备份一个步骤来查找X之前的提交。该提交也有一个快照


Git可以而且确实只提取两个快照，父快照和子快照，并对它们进行比较。对于每个相同的文件，Git什么都不说。对于每个不同的文件，Git向您展示了一个秘诀：从父文件的副本开始。在这里加上这一行。删除那个。根据需要重复，添加和删除完成后，将获得子提交中的文件版本

当您有一行简单的提交时，您可以绘制或思考它们，如下所示：

... <-F <-G <-H ...

...--G--H   <-- master, dev (HEAD)

          I
         /
...--G--H   <-- master, dev (HEAD)

          I--J
         /    \
...--G--H      M   <-- dev (HEAD)
         \    /
          K--L   <-- master

...--C--D--E   <-- branch1 (HEAD)
            \
             F--G--H   <-- branch2

我们实际上不需要将一个提交到下一个提交的连接箭头绘制为箭头，因为它们无法更改。任何提交的任何部分都不能更改。所以他们总是指向后面。但是，分支名称中的箭头会发生变化。我们可以从以下方面开始：

...--G--H   <-- master

但最终我们将向分支添加一个新的commit。让我们将特殊名称
HEAD
添加到
dev
中，以记住这是我们正在使用的名称，我们在运行
git checkout dev
时使用的名称，并按如下方式绘制：

... <-F <-G <-H ...

...--G--H   <-- master, dev (HEAD)

          I
         /
...--G--H   <-- master, dev (HEAD)

          I--J
         /    \
...--G--H      M   <-- dev (HEAD)
         \    /
          K--L   <-- master

...--C--D--E   <-- branch1 (HEAD)
            \
             F--G--H   <-- branch2

I
指向
H
，因为
H
是我们进行
I
时的当前提交

现在出现了一个聪明的技巧：Git将
I
的散列ID写入分支名称。更改的分支名称是附加到
dev
的
HEAD
名称。所以现在
dev
指向
I
，而不是
H
：

          I   <-- dev (HEAD)
         /
...--G--H   <-- master

不过，此时，我们可能会运行
git checkout master
和
git pull
（或
git fetch&&git merge
）并获取其他人所做的一些新提交。为了对称，我将画两张其他人所做的承诺。这也提升了我们的
主机
的两个新提交：

          I--J   <-- dev
         /
...--G--H
         \
          K--L   <-- master (HEAD)

我们现在可以合并这两个分支。我们实际上是在合并提交，因为Git完全是关于提交的，但让我们看看它是如何工作的

在我们的提交
I-J
中，我们对一些文件进行了一些更改。在他们的提交
K-L
中，他们对一些文件进行了一些更改。我们将要进行一次新的合并提交，此合并提交将保存一个快照，就像每次提交一样。此快照中应该包含什么内容

答案是：我们希望此快照与