9
讓我們來想象一下在git上維護的blerp命令行工具。該工具具有（隱藏的）--version選項，該選項返回其version（假設爲0.1.2），另一個--commit返回從其構建的提交編號。如何在Git中管理版本號？
版本號和提交號都在代碼庫上進行了硬編碼。
現在我犯了一個錯誤修正，然後提交併重建我的程序。儘管這個新版本與原來的0.1.2不同，我仍然會看到0.1.2。只有提交會告訴我它不是一樣的0.1.2。該修補程序是否值得不同的版本號？
一個解決方案是，每次進行提交時，我都會增加硬編碼的版本號（這意味着每次提交總是要修改至少2個文件）。這是一個有約束力的解決方案，當開發人員在不同的活動分支上工作時，它不起作用。如果Bob使用版本0.1.2的foo功能，並且Alice使用來自相同版本的功能bar。他們如何增加版本號？鮑勃可以使用奇數和愛麗絲偶數。如果夏娃在第三個功能上工作會怎樣？
另一個解決方案是使用Git標籤自動生成版本號。腳本可以找到v開頭的最近標記，如v0.1.2，並使用標記名稱作爲版本號加上當前提交的前n個數字（v0.1.2 (build 4acd21)）。如果工作目錄是乾淨的，這很好。可以想象在構建號之前添加*以指示工作目錄不乾淨。這種解決方案的主要問題是，如果有人導出源，它將無法構建blerp。
什麼可能的替代方案可以解決這個問題？
通常情況下，你應該避免把一個版本到源文件進行查看。理想情況下，您將有一個構建過程，將版本編碼爲內部版本號。這種方式的版本是獨立於用來構建它的源碼。那麼這個過程也可以在某個地方對提交ID進行編碼，所以你總是知道什麼是源代碼。至於存儲版本號，常用的解決方案是使用標籤。這也爲您提供了一些好處，您可以通過查看標籤，輕鬆瀏覽版本庫中的版本。 – poke
@poke如果您只有SCM的源代碼，您如何獲得產品中的版本號。 「blerp」的版本是什麼？ – nowox
通常，您發佈的內容與版本控制中的內容不完全相同。所以你可以像我描述的那樣在構建過程中應用這個版本。 – poke