開發人員希望使用來自 origin/master 分支的更新更改來更新 featureBranch，然后將他們的本地更改推送到 origin/featureBranch
git checkout featureBranch
git add .
git commit -n -m "message"
git checkout master
git fetch
git checkout featureBranch
git merge master --no-verify
git push origin featureBranch
我看到一個完全空白的提交（與 dev 合并），有 0 個添加和 0 個洗掉。為什么？
uj5u.com熱心網友回復：
問題中沒有足夠的資訊來說明您獲得合并提交的確切原因，但有幾種可能性：
合并提交是必要的。如果兩個分支提示提交都在共享（公共）合并基礎提交之前，則會發生這種情況。即使在進行合并時不涉及任何更改，這種情況也可能發生。
強制合并提交。MERGE如果您指定
--no-ff選項，GitHub 的按鈕總是會發生這種情況，而命令列 Git 會發生這種情況。您可以在配置中包含此選項，在這種情況下，我們不會在命令列上看到它。快進是可能的，但引數
git merge是標簽和標簽：未存盤在
refs/tags/層次結構中的自然位置（如檔案中所述
git merge，在--ff,--no-ff,--ff-only選項下）。
（按概率降序排列）。最后一個需要將名稱master決議為標簽物件，這不太可能但在技術上并非不可能。如果您配置merge.ff為false. 第一個是最有可能的，因為它很常見。
我看到一個完全空白的提交（與 dev 合并），有 0 個添加和 0 個洗掉。為什么？
沒有提交是空白的（也不是空的，盡管有git commit --allow-empty選項拼寫）。提交總是包含：
- 每個檔案的完整快照（使用通常的壓縮和重復資料洗掉），加上
- 元資料。
合并提交包含列出兩個或多個父哈希 ID的元資料：這就是它首先成為合并提交的原因。一個普通的（非合并）提交有一個父提交，并且每個非空存盤庫中至少有一個提交是第一個提交，因此沒有父提交，使其成為（通常是）根提交。每個提交也有每個檔案的完整快照：合并提交在這里沒有什么不同。
假設我們有以下一系列提交，以及兩個分支名稱br1并br2選擇它們的提示提交：
I--J <-- br1
/
...--G--H
\
K--L <-- br2
跑步：
git checkout br1 && git merge br2
如果一切順利，將M在分支上生成新的合并提交br1并留給我們：
I--J
/ \
...--G--H M <-- br1 (HEAD)
\ /
K--L <-- br2
提交的快照M是由以下人員制作的：
- finding the differences (various files changes) from
HtoJ; - finding the differences from
HtoLas well; - combining (merging) those differences; and
- applying the combined differences to the snapshot from commit
H.
This keeps the H-to-J changes and adds the H-to-L changes, if you like to view it that way, or it keeps the H-to-L changes and adds the H-to-J changes: sums are (at least for non-conflict cases) commutative, like integer arithmetic: 3 7 = 10, but 7 3 = 10 too.
If whoever made the br2 changes copied exactly the br1 changes, the "sum" that Git makes here will be to keep just one copy of the changes. So the snapshot in M will match both of those in J and L (which themselves both match). That would show as no additions and no removals.
If whoever made one of the two branches made a change, then reverted it, so that the snapshot in one of J or L matched the snapshot in H, that "side" of the merge would have no contribution, and the snapshot in M would match the other commit. If the "side" that had a net-zero contribution was br2, that too would show as no additions and no removals.
Without more (e.g., the output from git log --graph, perhaps with --oneline, and/or the results of git merge-base from before the merge plus the appropriate git diff commands to see what changes Git is merging, and/or the result of git config --get merge.ff) we can't say which of these might have triggered the "empty" merge (to misuse the word "empty" the way Git does).
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/443662.html