使用git控制語義版本控制

Question

在git中，我想“標記”某些提交。 例如，我想“標記”那些破壞了軟件的REST API的提交，這樣我就可以記得修改主要版本號。 （我使用語義版本控制 ）。

理想情況下，我應該能夠發出git命令來查看自上一個發行版/標記以來是否有任何提交包含“標記”，因為那樣我便知道下一個版本號。 應該撞大號。

由於標記是唯一的，因此“標記”不是標記（以git術語表示）。 我預計自上次發布以來可能會有幾個相同的“標記”，以表示API已損壞。

當前的解決方法是在提交消息中寫入“ MAJOR：”或“ MINOR：”。

關於如何使用git有什么建議嗎？

Answer 1

確實，標記名稱必須是唯一的—但是，有無限多個¹的獨特標記名稱以 mark/ 開頭 ，例如mark/1 ， mark/2等。 或者，您可以使用不在refs/tags/參考名稱； 或者，您也可以使用Git的“注釋”，盡管更容易檢測標簽或其他引用是一次提交的祖先還是另一次提交的后代：

highmark=$(git for-each-ref --format='%(refname)' refs/marks | wc -l)
nextmark=$((highmark + 1)
git update-ref refs/marks/m$nextmark HEAD

（這假設您絕不會使用git update-ref -d刪除任何這些標記-如果您執行“高標記”計算，則必須找到現有的最高數字，而不是簡單地計數）。 要測試標記$ N是否在標簽T1和HEAD之間：

if git merge-base --is-ancestor T1 refs/marks/m$N &&
   git merge-base --is-ancestor refs/marks/m$N HEAD; then
       ... mark N is at or beyond tag T1 and at or before HEAD ...
else
       ... mark N is not between those two points (inclusive) ...
fi

或者，您可以將其存儲在資源庫中或內部，如果在資源庫內部，則可以將其存儲在普通的Blob中（Blob是Git原始文件數據的內部格式），該文件僅包含所有“已標記”提交的哈希ID。 文件本身可以存儲在帶標記或其他引用的提交中，該提交可以但不必位於任何分支上。 或者您可以標記Blob本身。 例如：

git show marks > /tmp/all-marks      # extract existing marks
git rev-parse HEAD >> /tmp/all-marks # add a new mark
git tag -f marks $(git hash-object -w --stdin < /tmp/all-marks)

如果將Blob存儲在提交下，則可以通過為每個新的更新的“標記ID”文件進行新提交來保留標記的歷史記錄。 這在某些方面類似於git notes工作方式，但是您無需編寫名稱為提交ID的文件，而只是編寫一個名為“ marks”的文件（通過樹存儲，然后由提交指向該樹） ，即標記參考-是像上面的標記示例中那樣的refs/tags/marks之類的標記，還是上面的m系列參考中類似refs/marks參考，但僅使用一個參考）。 由於每個提交都有一個父指針，因此您可以保存上一個提交，保存上一個樹，保存上一個blob / marks-file，甚至可以對這些提交運行git log ，以查看何時更新了這些標記等

---

¹是有限的，但僅受磁盤空間和名稱模式的限制。 此處提出的模式，在單個名稱空間中的文件名中以小數點計數，在典型的Unix-ish文件系統上只能計數到10 ²⁵⁴ ，其組件名稱長度限制為255字節。 實際上，在將名稱分層之前，您可能不希望超過一千個左右，例如，一旦進入幾百萬個帶標記的提交，便是refs/marks/123/456/789 123/456/789。

操作系統還強加了最大路徑長度，但是您在提交ID之前就已經用光了：2 ¹⁶⁰僅是1 461 501 637 330 902 918 203 684 832 716 283 019 655 932 542 976，即短約1.462 sexdecillion 規模術語。 更糟糕的是，無論如何，在經過五百億個對象之后，發生哈希沖突的機會變得很高，因此我們只需要數10 ^18即可 。