git可以找出要合并的分支有过时的更改吗? [英] Can git figure out that the branch to be merged has obsolete changes?

问题描述

我是git的新手，我发现很难全神贯注于一切都围绕快照/提交而不是单个文件的事实.
因此，假设我的存储库中有一个树，如下所示.

I am new in git and I am find it hard to wrap my head around the fact that everything is around snapshots/commits and not individual files.
So assume that I have a tree in my repository as follows.

C4 (HEAD,Master,Origin/Master)  
*  
C3  
*  
C2  
*  
C1  

现在我从这里分支:

B1 (HEAD, testBranch)  
*  
C4 (HEAD,Master,Origin/Master)  
*  
C3  
*  
C2  
*  
C1  

在我的testBranch中，我只修改了整个存储库的2个文件.才2.
远程存储库中master的开发仍在继续，因此最终我们有了以下树:

In my testBranch I only modify 2 files of the whole repository. Just 2.
The development in master in the remote repository continues so eventually we have the following tree:

                    C8(Master,Origin/Master)   
                    *   
B3(testBranch)    C7   
  *              *   
  B2           C6  
    *         *
     B1    C5   
       *  
       C4  
       *  
       C3  
       *  
       C2  
       *  
       C1  

现在，我已经完成了分支工作，并希望合并到master.但是大师已经向前迈进了一步.
但是B3最新版testBranch和C8最新版master之间的唯一区别是分支分支时我最初开始处理的2个文件中的更改.但是另外，由于发生了其他修改，因此testBranch紧随master分支之后.
那么，如果我将testBranch合并到master，会发生什么?
git会确定要合并的唯一更改是我最初处理的2个文件吗?
我会发生冲突吗?我不应该合并但要重新设置基准吗?为什么?

Now I have finished working on the branch and want to merge to master. But the master has moved further ahead.
But the only difference between B3 the latest of testBranch and C8 the latest of master are the changes in the 2 files that I originally started to work on when I forked the branch. But additionally testBranch is "lest behind" the master branch since other modifications have occurred.
So what will happen if I merge testBranch to master?
Will git figure out that the only changes to merge are the 2 files I originally worked on?
Will I get conflicts? Should I not do a merge but a rebase? Why?

推荐答案

我发现我很难全神贯注于一切都围绕快照/提交而不是单个文件的事实.

I am find it hard to wrap my head around the fact that everything is around snapshots/commits and not individual files.

您以前使用过ClearCase吗?
如果是，请参见此问题以文件为中心的VCS(此处为 CVCS )和DVCS 就像git(在这里介绍的 ).

Did you used ClearCase before?
If yes, see this question for a difference between a file-centric VCS (here a CVCS) and a DVCS like git (that I introduce here).

那么，如果我将testBranch合并到master，会发生什么? git会找出要合并的唯一更改是我最初处理的2个文件吗?

So what will happen if I merge testBranch to master? Will git figure out that the only changes to merge are the 2 files I originally worked on?

是

但是git如何理解"分支中的不同代码已被master中的代码过时了?由于时间戳记?

But how does git "understand" that the different code in the branch has been made obsolete by the code in master? Due to timestamps?

由于每个提交都知道其父级，因此可以在B3(合并到)C8:共同祖先提交. >.

Due to the fact that each commit knows its parent: that allows to find a common ancestor commit between B3 (merged to) C8: C4.

合并操作知道自C4以来发生了什么变化:仅2个文件，它将仅将那些文件合并到master.

The merge operation know what has evolved since C4: only 2 files, and it will merge only those to master.

另请参阅"是什么使DVCS中的合并变得容易?.

合并操作知道自C4以来发生了什么变化:仅2个文件，它将仅将那些文件合并到master.

The merge operation know what has evolved since C4: only 2 files, and it will merge only those to master.

但是B1-C5 B2-C6是不同的.
例如. B1和B2中存在的C5中的功能可能已被删除.
我不确定我是否理解它是如何解决的，并且它不会重新包含"函数

But B1-C5 B2-C6 are different.
E.g. a function in C5 that exists in B1 and B2 could have been deleted.
I am not sure I understand how does it figure this out and it doesn't "reinclude" the function

它会找出并不重新引入该功能，因为:

It does figure out and not reintroduce that function because:

• 该功能存在于C4(共同祖先)
中
• 该功能存在于B2中(因此在合并的源分支上没有任何更改)
• 该功能在master中不再存在(但这是一个更改，在此处为删除，这会影响合并的目标分支)

• that function existed in C4 (common ancestor)
• that function existed in B2 (so no change there on the source branch of the merge)
• that function no longer exist in master (but it is a change, a deletion here, which affects the destination branch of the merge)

合并是关于报告和合并从源分支到目标分支的修改.
您所指的只是目标分支中的修改，而源分支与公共祖先相比并没有发展:

A merge is about reporting and merging modifications from the source branch to the destination branch.
You are referring to a modification in the destination branch only, while the source branch has not evolved compared to the common ancestor:

• testBranch中的该功能将被合并忽略，因为没有要报告的修改.
• master中已删除的功能将被合并删除，因为合并会忽略testBranch中的所述功能(原因是我在上一点中提到的原因:自共同祖先起就没有修改)

• that function from testBranch will be ignored by the merge since there no modification to report.
• that deleted function in master will be kept deleted by the merge, since the merge ignores said function from testBranch (for the reason I just mentioned in the previous point: no modification since the common ancestor)

我会发生冲突吗?

Will I get conflicts?

如果这两个文件在master中也发生了更改(并且这些更改发生在公共行上)，您可能会发生冲突

You could get a conflict if those two files have also changed in master (and if those changes occurred on common lines)

我不应该合并但要重新设置基准吗?为什么?

Should I not do a merge but a rebase? Why?

如果您不按yes(是)testBranch并进行其他提交(但要基于master的最新版本来执行)，则重新设置基准会更好.

A rebase would be better if you didn't pushed yes testBranch, and have other commits to do on it (but want to do them based on a up-to-date version of master)

这篇关于git可以找出要合并的分支有过时的更改吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！