Question

我有两个分支：master和branch2。

它们仅在1行上有所不同：

主评论：//测试00

branch2有评论：//测试99

假设我从branch2开始，然后合并到master，那一行是

//测试00或//测试99？当我尝试使用git bash时，它返回消息“由“递归”策略进行的合并”。但实际上并没有向我显示这些更改。

PS C:\Node\projects\n-5-10-workflow-test> git checkout branch2
 Switched to branch 'branch2'
PS C:\Node\projects\n-5-10-workflow-test> git status
 On branch branch2
 nothing to commit, working tree clean
PS C:\Node\projects\n-5-10-workflow-test> git remote show origin
 * remote origin
 Fetch URL: https://github.com/masterinex/workflow.git
 Push URL: https://github.com/masterinex/workflow.git
 HEAD branch: master
 Remote branches:
  branch2 tracked
  master tracked
 Local branch configured for 'git pull':
  master merges with remote master
 Local refs configured for 'git push':
  branch2 pushes to branch2 (fast-forwardable)
  master pushes to master (up to date)
PS C:\Node\projects\n-5-10-workflow-test> git status
 On branch branch2
 nothing to commit, working tree clean
PS C:\Node\projects\n-5-10-workflow-test> git branch -a
 * branch2
 master
 remotes/heroku/master
 remotes/origin/branch2
 remotes/origin/master
PS C:\Node\projects\n-5-10-workflow-test> git merge master
 Merge made by the 'recursive' strategy.
PS C:\Node\projects\n-5-10-workflow-test>

Answer 1

[分支master和branch2]仅在1行上有区别：

主评论：//测试00

branch2有评论：//测试99

这不是没有用，但也不是完全使用 ful 信息。当您对git merge的功能感兴趣时，每个分支的提示内容都是 not 答案的键。更准确地说，它们是必要的，但远远不够。

首先，请记住，提交包含文件。我假设当您说“ master具有X和branch2具有Y”时，您的意思是真的：分别由master和branch2标识的提示提交中的所有文件都是相同，除了某些文件 F ，该文件的某些行 L 的文本不同：该行分别读取//test 00中的master和{{ 1}}在//test 99中。

也就是说，如果我们要绘制提交图，它可能看起来像这样：

branch2

（还有其他可能的形状，但是o--o--X <-- master / ...--o--* \ o--Y <-- branch2 (HEAD)的输出表明它很像这样。git merge后面附加了名称HEAD，因为这是您检查过的形状-）。

这里我使用branch2和X来表示分支Y和master的 tip commit 的实际哈希ID。因为每个提交都包含其直接上级提交的哈希ID，所以我们可以从branch2上的最后一次提交向master上的上一次提交进行反向操作，然后从那里到 its < / em>先前的提交，依此类推。我们也可以从提交master开始并向后移动。当我们同时从 both 提交向后移动时，我们最终将达到一些联合点：提交Y，而不是回合*之一。

第一个这样的连接点对于o非常特殊，因为它是合并基础。合并基础是了解git merge将要执行的操作的关键。

合并的目标是合并工作，而不是简单地使两个分支相同。为了结合完成的工作，Git必须找出工作是什么。这项工作包括自共同起点以来所做的所有更改。合并的基础就是那个共同的起点。

Git现在实际上将运行两个单独的git merge命令。可以将提交git diff与提交*进行比较，以查看分支X上的“他们”（无论它们是什么）。另一个将提交master与提交*进行比较，以查看您在分支Y上所做的事情。那就是：

branch2

Git然后组合这两组更改，并将组合的更改应用于提交git diff --find-renames <hash-of-*> <hash-of-Y> # what did we change, on branch2? git diff --find-renames <hash-of-*> <hash-of-X> # what did they change, on master?的内容。

由于您显然在*中所做的所有事情都与他们在branch2中所做的一样，所以除了改变了 L F 的em>，除此行外，合并的更改将相同。现在的问题是：谁更改了线路？

假设在master中，该行显示为*。然后 you 更改了该行，因此Git会进行您的更改，结果将是文件 F L em>将显示为//test 00。

但是让我们说，在//test 99中，该行显示为*。然后他们更改了该行，因此Git会进行他们的更改，结果将是文件 F L em>将显示为//test 99。

最后，在//test 00中，该行可能会完全读取其他内容。在这种情况下，您和他们俩都将 same 文件的 same 行更改为两个不同的内容。在这种情况下，*将声明存在冲突，并将停止并留下您必须清除的混乱情况。既然没有发生，显然不是这样。

检查文件将告诉您Git保留了哪些更改，而这又将告诉您该行在合并基础中的外观。或者，您可以自己找到合并基础，然后在特定提交中检查该文件的版本。但是，鉴于您告诉我们的内容，我们无法预测合并提交中的哪一行。

Answer 2

进行 git合并时，会将主分支带到实际分支。

//on branch branch2
git merge master

MASTER中的所有内容都将进入BRANCH2

BRANCH2 <--------- MASTER

Answer 3

您的合并已将您的本地master分支合并为您的本地工作分支（branch2）。因为没有冲突，所以该行的历史可能如下：

|
* (master)         // test 99
|\
| * (branch2)      // test 99
* | (master)       // test 00
|\|
| * (branch2)      // test 00

意味着当前分支上的文件应包含文本// test 00。

这似乎是您的问题，但是简单的grep '// test' <the file>会回答您的问题...

Answer 4

对您问题的简短回答“假设我从branch2开始，然后合并到master，那么该行应该是“ // test 00”还是“ // test 99“ ：

如果要将branch2合并到master中，并且branch2已从master分支出来，则答案是“ // test 99”。

但是，如果在创建master的那个时间点的branch2中的那行代码已从“ // test 00” 的原始值进行了修改，那么您将发生合并冲突。

如果branch2是从另一个分支创建的，没有根回到master，则可能会发生冲突。但是默认情况下，在git中，所有分支都返回到标记为master ...的分支，除非该存储库中存在一些时髦的分支历史。

如何做git合并正确的方法

4 个答案: