一個專案具有以下結構：一個master唯一提交的分支M，一個develop分支（垂直分支）和許多release-X.Y分支（水平分支）。' os 是常規提交并且*是vX.Y.Z-tagged 提交。分支中的一些有用改進release-X.Y被合并回develop（圖中未顯示）。
o -- * -- o -- o -- *
|
o
|
o -- o -- *
|
o
|
M
如何在master不改變現有結構的情況下使分支以正確的[即字典順序]順序“編織”和“編目”所有標記的提交？
也就是說，如果水平分支是release-0.1andrelease-0.2并且標記的提交v0.1.0, v0.2.0and v0.2.1，如何制作master這樣git log master會產生（模額外資訊）
v0.2.1
v0.2.0
v0.1.0
M
在圖中它會像
.__________.
/ \
o -- * -- o -- o -- *
| \
o \
| \
o -- o -- *
| /
o .___/
| /
M./
（當然，特定的樹以及是否標記了所需的提交最終對問題無關緊要，但希望它有助于構建激發問題的背景關系：對master軟體的所有“官方”提交進行編目。）
merge我已經使用、和命令查找了可能性commit，但似乎都沒有作業（有些可以創建新的內容等效提交，但目標是保持相同的精確標記提交）。rebasecherry-pick
三個問題的標題相似，但意圖卻大不相同：一、二和三。
我認為可以使用手動設定參考和物件的低級指令以master正確的方式堆疊標記的提交，但我更希望有一個更系統、更高級別的解決方案（如果有的話）。
uj5u.com熱心網友回復：
有些可以創建新的內容等效提交，但目標是保持相同的精確標記提交
你不能。Git 提交，包括它的出身，是不可變的。也是一件好事！否則 Git 將毫無用處。
因此，創建“新的內容等效提交”正是您需要做的。
uj5u.com熱心網友回復：
（先看馬特的回答。）
在 Git 中繪制分支有點棘手。
在某些版本控制系統中，分支是真實存在的。也就是說，你創建一個分支并用提交填充它，這些提交在那個分支上，并且只有那個分支，現在和永遠。所以當在這樣的倉庫中繪制提交時，我們可以將分支名稱放在左邊，并在右邊列出提交，如下所示：
br1: A--B--C
br2: D--E--F
br3: G--H
只要提交繼續存在，提交C就（僅）打開，并且將永遠永遠在該分支上。br1提交（僅）H處于br3啟用狀態，并且同樣將永遠位于該分支上。如果沒有分支，我們就不能有提交（盡管至少在理論上，我們可以有沒有提交的分支）。
但這在 Git 中是不正確的。在 Git 中，分支名稱是一個可移動的標簽。它沒有單獨的存在：它是短暫的、不真實的，只是一個消逝的影子。它的目的是幫助我們定位一個特定的提交，我們稱之為分支的提示提交。因此，如果我們像上面那樣從左到右繪制提交，我們應該把分支名稱放在右邊。
在 Git 中，提交之間的連接不存在，因為它們“在”哪個分支。相反，它們是提交本身的永久一部分。這些連接獨立于任何分支而存在。我們甚至可以有根本不在分支上的提交，因為提交本身是獨立于分支的。
在 Git 中，我們不能擁有的是沒有提交的分支。分支名稱的存在需要它指向一個特定的提交，并且多個名稱可以指向任何特定的提交。所以我們必須在右邊畫出名稱，從它們中出來的箭頭表明它們指向的是哪個提交：
A--B--C <-- br1
\
D--E--F <-- br2
\
G--H <-- br3
提交A-B-C在所有三個分支上；向上提交F是在兩個分支上（它們不是“打開” br1，而是在兩個分支br2上br3）；并且提交G-H只在一個分支上，br3. 至少，現在是這樣。如果我們選擇這樣做，我們可以完全洗掉該名稱br1：
A--B--C
\
D--E--F <-- br2
\
G--H <-- br3
我們不再需要圖中的第一個扭結點，在C和之間D，因為向上提交F都在剩下的兩個分支上。 G-H只保留在 上br3。如果我們也洗掉br2，所有提交現在都在一個分支上，br3. 我們甚至可以創建一個新名稱 ，br4或重新創建舊名稱br1，或移動它：
A--B--C--D--E--F--G--H <-- br1, br3
現在所有提交都在兩個分支上。
這意味著在一個非常重要的意義上，Git 的分支不是真實的。他們甚至不存在！如果某樣東西今天是 X，但明天是 Y，那么稱它為 X 有什么意義？1 當然，我們這些短暫的人類對其他短暫的事物有一種喜愛，所以我們繼續使用這些幻影，只要它們幫助和/或娛樂我們。
這里真正的教訓是你不能也不應該過分依賴Git 中的分支。它們只是臨時服務物體。標簽名稱，如果使用得當，2更可靠：使用標簽來標記具有某種歷史意義的提交。
1緊急情況，可能。??
2 Git 不會讓您移動標簽，因此除非您使用git tag -f強制重新創建現有標簽，或洗掉然后重新創建標簽，否則任何特定標簽選擇的提交哈希 ID保持不變。我們可以只使用原始哈希 ID，但人類對此有反感。
（請注意，在 1.8.2 之前，Git 在 期間意外地將分支名稱規則應用于標記名稱更新git fetch。也就是說，當且僅當它是快進時才允許名稱移動。這只是一個錯誤。）
uj5u.com熱心網友回復：
您不能在提交時僅更改分支上的某些提交。但是，您可以在git log您的分支時進行類似的操作，主要由合并組成。將每個版本一個接一個地合并到主分支中：
git checkout master
git merge vX.Y.Z
git merge vX2.Y2.Z2
...
您可能希望使用theirs合并策略來確保在發生合并沖突時在 master 中獲得最新版本，而不必手動解決沖突。
您可以使用“--first-parent”選項僅顯示合并提交，即每個版本一個git log
git log --first-parent master
將僅向您顯示所有合并提交，這將與發布具有 1:1 對應關系。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/466866.html
標籤：混帐