hid*_*dar 3 git git-merge git-fetch
如果两个人在 github 上的同一个存储库和同一个分支 master 上工作。然后说 A 将他们的更改推送给 master,而我作为 B,我如何在调用后检查更改的文件git fetch
?
如果我做:
git fetch
git merge master origin/master
Run Code Online (Sandbox Code Playgroud)
我得到这一行:
aa@DESKTOP-KQQ0A3T MINGW64 ~/..
$ git merge master origin/master
Merge made by the 'recursive' strategy.
src/main.js | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
Run Code Online (Sandbox Code Playgroud)
我喜欢src/main.js
以这种方式描述差异的方式,但该信息仅在我合并时出现,所以我的问题是,在进行合并之前,我应该使用什么命令来查看有关差异的相同信息?
在我回答之前,先快速说明一下:
Run Code Online (Sandbox Code Playgroud)git merge master origin/master
请不要这样做:您只想要git merge origin/master
,而不是git merge master origin/master
。(幸运的是, master
当您运行此程序时,您处于开启状态,因此 Git 最终忽略了该master
部分。如果没有,您会看到Merge made by the octopus strategy
。)
我们先回答这部分:
我喜欢
src/main.js
以这种方式描述差异的方式,但该信息仅在我合并时出现,所以我的问题是,在进行合并之前,我应该使用什么命令来查看有关差异的相同信息?
要查看git merge
会说些什么(假设您的工作树是“干净的”,其中git status
会说“无需提交”),请运行:
git diff --stat HEAD...HEAD@{upstream}
Run Code Online (Sandbox Code Playgroud)
它--stat
是生成摘要的对象。让我们暂缓讨论git diff
这里的论点;但让我们注意(因为这很重要),这假设了一个简单的、普通的单合并基提交合并,或者一个快进操作(这些很可能)。
如何检查调用后更改的文件
git fetch
?
这个问题本身揭示了一些混乱(自然的混乱,因为 Git 非常混乱 :-) )。具体来说,git fetch
没有改变任何文件。 什么git fetch
做的是获得新的提交。每一次提交都是一个快照——一份你创建快照时所有文件的副本——并且快照本身并不是一个更改。
但与此同时,如果您查看带有git show
或的快照git log -p
,Git 将显示更改。如果快照是快照,而不是变更集,那么 Git 如何显示变更? 好吧,经过一番思考,答案显而易见。这就像那些“发现差异”图片/测验之一:
git show
即使提交是快照,这也是向您显示更改集的方式。提交有一个父提交和Git只是相比较,用git diff
,家长hash~1
或者hash^1
,用其哈希是提交hash
。(~1
和^1
后缀都退回 Git 图中的第一个父节点。)
git diff
及其论点该git diff
命令非常复杂,因此它可以做的不止这些,但大致来说,它只是比较两个完整的快照。您如何命名它们并不重要:
git diff origin/master master
Run Code Online (Sandbox Code Playgroud)
例如,将找到origin/master
命名的提交——哈希 ID——以及命名的提交,master
然后比较两者。输出是一组指令:这是如何更改第一个提交以使其看起来像第二个提交。
你可以写:
git diff origin/master..master
Run Code Online (Sandbox Code Playgroud)
若你宁可。当你用 做这种事情时git log
,你经常会看到很多提交,而不仅仅是两个。该git diff
命令是不同的:它只是看起来在这两个提交。实际上,它丢弃了..
部分(当然,它们用于分隔两个名称)。
说到合并,还有另一种特殊的git diff
语法:git diff A...B
means git diff $(git merge-base A B) B
。这就是我们上面使用的。通常,三点语法具有不同的含义;git diff
相反,将其更改为这个特定的“告诉我合并会做什么”的含义。
(这不是完成合并后git merge
最后运行的内容,因为在合并完成后,合并基础发生了变化。而且,如果合并基础不仅仅是单个提交,则语法无论如何都会选择单个提交,并比较这两个提交,而将默认为更复杂的策略。因此,在真正的合并完成后,Git 可以直接运行,这本质上就是它所做的。对于快进的非真正合并“合并”,Git 可以运行。)git diff A...B
git merge
git diff --stat HEAD^ HEAD
git diff --stat HEAD@{1} HEAD
欲了解更多的普通和特殊的Git的Diff-才有意义有三个点的符号,请参阅该gitrevisions文档和该git diff
文档。
归档时间: |
|
查看次数: |
3435 次 |
最近记录: |