我在運行 GIT 時遇到問題：
git checkout refs/remotes/pull/534/merge
在公共存盤庫上：
https://github.com/raycast/extensions
根據檔案，它應該模擬合并 PR 時會發生的合并 - 我希望這會模擬與 HEAD 的合并main，但如果與歷史上奇怪的提交合并。
我在這里錯過了什么嗎？這是我喜歡通過 PR 檢測更改檔案的其他一些問題的根本原因。
uj5u.com熱心網友回復：
根據檔案，它應該模擬合并 PR 時會發生的合并...
這不是模擬合并。相反，GitHub 實際上已經做了一個合并。
我期待這會模擬與 main 的 HEAD 合并，但是如果與歷史中的一個奇怪的提交合并。
Git 中的合并（因此也在 GitHub 1中）實際上并不是在分支之間。那是因為在一個重要的意義上，分支在 Git 中甚至不存在。2 合并提交確實存在，所以如果我們繞過這個令人困惑的“究竟什么是分支”問題，直接進入合并提交，我們會得到一些我們可以輕松討論的東西：
合并提交很像常規提交。常規提交有一個快照——在你（或任何人）提交時出現的每個檔案的完整副本——以及說明誰提交、何時提交等的元資料。
正常提交的元資料中存盤了一個父提交哈希 ID。這將提交鏈接在一起，形成一個向后看的鏈。這個提交鏈就是 Git 存盤庫中的歷史：提交就是歷史；歷史只不過是一系列提交。
合并提交的元資料使提交成為合并提交：它列出了兩個父級3并且這兩個父級提交都是該提交的歷史記錄。兩個父提交之一（第一個）是進行合并提交的提交。兩個父母中的另一個，因此是第二個，是合并的提交（不是“分支”，因為這是不明確的）。
GitHub 用作第一個父級的提交是在您（或任何人）發布您的（或他們的）拉取請求時作為“基礎分支”（GitHub 特定術語）的尖端的提交。GitHub 將用作第二個父級的提交是您（或任何人）PR 尖端的提交。從那時起，其他人就有可能向那個“基礎分支”添加新的提交。測驗合并針對舊的分支提示提交。任何提交，一旦做出，就永遠不能改變，所以這個測驗合并是永遠的方式。你未來的實際合并，如果你這樣做，可能會有所不同：不同的提交，具有不同的哈希 ID 和不同的父級。未來實際合并的第一個父級將是 GitHub 進行最終合并時分支的尖端；未來實際合并的第二個父級將是您的拉取請求的提示，您可以在此期間對其進行更新。
是否以及何時應該使用此測驗合并，或者進行自己的合并，是一個只有您才能回答的問題。你在這里控制：你選擇。您可以使用refs/pull/534/head來參考 PR 本身的提示提交（測驗合并中的父 #2），并且 - 如果存在 - 您可以使用refs/pull/534/merge來參考 GitHub 測驗合并。如果 GitHub 測驗有合并沖突，refs/pull/534/merge則不會存在，除非并且直到有人使用 GitHub 介面來解決合并沖突。
1 GitHub 實際上并不直接使用 Git。相反，他們使用了一種增強的 Git 子集。但是，只要合并沒有沖突，合并結果是相同的。當合并發生沖突時，GitHub 原本根本無法進行合并；他們現在通過他們的增強提供了一種解決沖突的方式，這不是 Git 的一部分。這種非 Git GitHub 特定的沖突解決方法僅在 GitHub 上可用，因為他們 (GitHub) 自己創建了它。
2Of course, in other senses, branches do exist. The trick is defining exactly what we mean by branch. See also this SO question, which gets into the various underlying things that do exist, what we call them, and how people confuse them with each other. See also this Wikipedia article, which touches on the metaphysics of naming.
3So-called octopus merges have more than two parents. They don't really do anything you can't do with ordinary merges, though, so we'll just skip right over them for this answer.
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/426184.html