合并后 2 个分支之间的差异：GIT
Differences between 2 branches after merge: GIT
我目前正在开发名为 NC12-changePassword 的第二个分支。
对处理字符串解密的 master 分支进行了更改。我需要这些新更改才能在我的分支上实现新功能，因此我合并了这些更改。
我做了 git 拉动，没有冲突。当我 运行 git log 它显示合并提交。此外，当我 运行 git merge master 它告诉我一切都是最新的。
但是我的代码不起作用，当我 运行 git diff NC12-changePassword master 时，它列出了 master 中不在 NC12-changePassword 中的内容。这对我来说没有意义，因为我合并了更改，因此 master 中的所有内容都应该在 NC12-changePassword.
中
我的理解是我的分支应该像 master 一样工作并且代码应该可以正常工作。或者我错过了什么 :-\ .
and therefore the everything that is in master should be in NC12-changePassword
这不是 "merge" 的意思，因此也不是 git merge 的意思。
我们举一个很简单的例子来说明。假设您在 master 之外创建了一个分支，并且作为该分支的一部分甚至全部，您删除了一段代码并提交了结果。
然后，在您完成此操作后，假设 Fred 修改 master 以添加第二个代码块（可能完全在另一个文件中），只有在第一个代码块存在时才做一些有用的事情。他向 master.
承诺
稍后，您在 master 中获得 Fred 的工作并使用 git merge 将 his-changes-to-master 引入您的分支。 Git 不会 放回您删除的代码：它假设您当时知道自己在做什么。它所做的只是发现 Fred 添加了一个 new 代码块，它会将相同的代码块添加到您的分支，它什么都不做，因为它取决于您删除的代码块。
如果您现在将您的分支与 Fred 的 master 进行比较，您仍将有一个已删除的代码块：您删除的块。你不会所有 master。 （你自己的 master 可能也没有 Fred 的变化，因为在上面，我们从未提到你开始 你的 master 并引入他的从他的 master 改变而来。）
在复杂的情况下，您必须使用自己的知识（永远超过 git 的知识）来修复语义不正确的合并。 Git 最多会注意到句法冲突，例如："hey, you deleted this block of code, but Fred made a change to that same block, so since I, git, know nothing of semantics, you will have to resolve this conflict"。但这只有在您足够幸运地遇到句法冲突时才会发生。如果 Fred 的更改 "fit in" 尽管有你的更改，但因为你的更改什么都不做，git 甚至不会注意到。
我目前正在开发名为 NC12-changePassword 的第二个分支。
对处理字符串解密的 master 分支进行了更改。我需要这些新更改才能在我的分支上实现新功能，因此我合并了这些更改。
我做了 git 拉动，没有冲突。当我 运行 git log 它显示合并提交。此外，当我 运行 git merge master 它告诉我一切都是最新的。
但是我的代码不起作用，当我 运行 git diff NC12-changePassword master 时，它列出了 master 中不在 NC12-changePassword 中的内容。这对我来说没有意义，因为我合并了更改，因此 master 中的所有内容都应该在 NC12-changePassword.
我的理解是我的分支应该像 master 一样工作并且代码应该可以正常工作。或者我错过了什么 :-\ .
and therefore the everything that is in master should be in NC12-changePassword
这不是 "merge" 的意思，因此也不是 git merge 的意思。
我们举一个很简单的例子来说明。假设您在 master 之外创建了一个分支，并且作为该分支的一部分甚至全部，您删除了一段代码并提交了结果。
然后，在您完成此操作后，假设 Fred 修改 master 以添加第二个代码块（可能完全在另一个文件中），只有在第一个代码块存在时才做一些有用的事情。他向 master.
稍后，您在 master 中获得 Fred 的工作并使用 git merge 将 his-changes-to-master 引入您的分支。 Git 不会 放回您删除的代码：它假设您当时知道自己在做什么。它所做的只是发现 Fred 添加了一个 new 代码块，它会将相同的代码块添加到您的分支，它什么都不做，因为它取决于您删除的代码块。
如果您现在将您的分支与 Fred 的 master 进行比较，您仍将有一个已删除的代码块：您删除的块。你不会所有 master。 （你自己的 master 可能也没有 Fred 的变化，因为在上面，我们从未提到你开始 你的 master 并引入他的从他的 master 改变而来。）
在复杂的情况下，您必须使用自己的知识（永远超过 git 的知识）来修复语义不正确的合并。 Git 最多会注意到句法冲突，例如："hey, you deleted this block of code, but Fred made a change to that same block, so since I, git, know nothing of semantics, you will have to resolve this conflict"。但这只有在您足够幸运地遇到句法冲突时才会发生。如果 Fred 的更改 "fit in" 尽管有你的更改，但因为你的更改什么都不做，git 甚至不会注意到。