名稱

gitworkflows  - 使用 Git 推薦的工作流程概述

概要

git *

描述

本文檔試圖寫下并激勵一些用于git.git其自身的工作流元素。一般來說，許多想法都適用，盡管涉及較少人員的較小項目很少需要完整的工作流程。

我們制定了一套rules快速參考，試圖激勵他們每個人。不要總是從字面上理解它們; 你應(yīng)該重視你的行為的好的理由比manpages更高，比如這個。

單獨更改

作為一般規(guī)則，您應(yīng)該嘗試將您的更改分成小邏輯步驟，并提交它們中的每一個。它們應(yīng)該是一致的，獨立于任何后續(xù)的提交，通過測試套件等，這使得評審過程變得更加容易，并且歷史對以后的檢查和分析更有用，例如使用 git-blame [1] 和 git -bisect [1] 。

要做到這一點，請嘗試從一開始就將工作分成幾個小步驟。把一些承諾壓在一起比把一個大承諾分成幾個承諾總是更容易。不要害怕在這個過程中做出太小或不完美的步驟。您可以稍后返回git rebase --interactive并在發(fā)布之前編輯提交。您可以使用git stash save --keep-index獨立于其他未提交的更改來運行測試套件; 請參閱 git-stash [1] 的 EXAMPLES 部分。

管理分支

有兩個主要的工具可以用來包含另一個分支的變化： git-merge [1] 和 git-cherry-pick [1] 。

合并有很多優(yōu)點，所以我們試圖通過合并來解決盡可能多的問題。Merging upwards仍然偶爾有用; 例如，請參閱下面的“向上合并”。

最重要的是，在分支層面合并工作，而 Merging upwards 在提交層面工作。這意味著合并可以平等地承擔(dān)1,10或者1000次提交的變更，這意味著工作流程對于大量貢獻(xiàn)者（和貢獻(xiàn)）的擴展要好得多。合并也更容易理解，因為合并提交是一個“承諾”，其中包含所有父母的所有更改。

當(dāng)然有一個折衷：合并需要更仔細(xì)的分支管理。以下小節(jié)討論重要的一點。

Graduation

由于特定功能從實驗到穩(wěn)定，它也是軟件相應(yīng)分支之間的“graduates”。git.git使用以下內(nèi)容integration branches：

• maint 跟蹤應(yīng)該進(jìn)入下一個“維護版本”的提交，即更新最后發(fā)布的穩(wěn)定版本;

• master 跟蹤應(yīng)該進(jìn)入下一個版本的提交;

• next 旨在作為測試主題的測試分支，用于測試 master 的穩(wěn)定性。第四個官方分支的用法稍有不同：

• pu （提議的更新）是一個尚未準(zhǔn)備好包含的事物的集成分支（請參閱下面的“集成分支”）。

四個分支中的每一個通常都是它上面的直系子代。

從概念上講，功能進(jìn)入一個不穩(wěn)定的分支（通常next或pu），“graduates” 進(jìn)入master下一個版本，一旦被認(rèn)為足夠穩(wěn)定。

向上合并

上面討論的“向下的分級”不能通過實際向下合并來完成，但是，因為這會將all不穩(wěn)定分支上的變化合并到穩(wěn)定分支中。因此如下：

規(guī)則：向上合并

始終將修復(fù)提交給需要它們的最早受支持的分支。然后（定期）將集成分支向上并入彼此。

這提供了一個非常受控制的修復(fù)流程。如果你注意到你已經(jīng)應(yīng)用了一個修補程序，例如master它也是必需的maint，你需要向下選擇它（使用git-cherry-pick [1]）。這會發(fā)生幾次，沒有什么可擔(dān)心的，除非你經(jīng)常這樣做。

topic branches

任何不平凡的功能都需要多個補丁才能實現(xiàn)，并且可能會在其生命周期中得到額外的錯誤修復(fù)或改進(jìn)。

在集成分支上直接提交所有內(nèi)容會導(dǎo)致很多問題：錯誤提交不能撤消，因此必須逐一恢復(fù)，這會導(dǎo)致當(dāng)您忘記恢復(fù)一組更改的一部分時，會產(chǎn)生令人困惑的歷史記錄和更多的錯誤可能性。并行工作會混淆變化，進(jìn)一步造成混亂。

使用 “topic branches” 解決了這些問題。這個名字很自我解釋，有一個警告來自上面的“合并向上”規(guī)則：

規(guī)則：主題分支

為每個主題（功能，錯誤修正...）建立一個支路。把它關(guān)在最早的整合分支上，你最終想要將它合并到它。

很多事情可以很自然地完成：

• 要將功能/錯誤修復(fù)引入集成分支，只需將其合并即可。如果話題進(jìn)一步發(fā)展，再次合并。（請注意，您不一定必須先將其合并到最早的集成分支，例如，您可以先將一個錯誤修正合并到next該測試中，給它一些測試時間，并maint在知道它穩(wěn)定時合并。）

• 如果您發(fā)現(xiàn)需要分支的新功能other才能繼續(xù)處理主題，請合并other到topic。（但是，不要只是“習(xí)慣性地”這樣做，見下文。）

• 如果你發(fā)現(xiàn)你錯誤的分支，并想“移回”時間，請使用 git-rebase [1]。注意最后一點與另外兩個分支沖突：在其他地方合并過的主題不應(yīng)該重新分配。我們應(yīng)該指出，“習(xí)慣性地”（定期沒有真正的理由）將一個整合分支合并到你的主題中 - 并且通過擴展將任何上游合并到任何下游的任何東西上規(guī)則：僅在定義明確的點處合并到下游不合并到下游，除非有一個很好的理由：上游 API 更改會影響您的分支; 你的分支不再合并到上游干凈; 等等。另外，被合并的主題突然包含多個單獨的（完全分離的）更改。由此產(chǎn)生的許多小規(guī)模合并將大大混亂歷史。任何后來調(diào)查文件歷史的人都必須查明合并是否影響了開發(fā)中的主題。上游甚至可能會無意中合并成一個“更穩(wěn)定”的分支。等等。縮小整合如果你按照最后一段，現(xiàn)在你會有很多小的主題分支，偶爾也會想知道它們是如何相互作用的。也許合并它們的結(jié)果甚至不起作用？但另一方面，我們希望避免將它們合并到“穩(wěn)定”的任何位置，因為這樣的合并不能輕易地被撤消。當(dāng)然，解決方案是進(jìn)行可以撤消的合并：合并到一個丟棄分支中。規(guī)則：丟棄集成分支為了測試幾個主題的交互，將它們合并到一個丟棄分支中。

• git.git有一個正式的拋棄式集成分支稱為pu分支管理，用于釋放假設(shè)您正在使用上面討論的合并方法，當(dāng)您發(fā)布項目時，您需要執(zhí)行一些額外的分支管理工作。從master分支創(chuàng)建功能發(fā)布，因為master跟蹤應(yīng)該進(jìn)入下一個功能發(fā)布的提交。該master分支應(yīng)該是一個超集maint。如果這個條件不成立，那么maint包含一些不包含的提交master。這些提交所代表的修復(fù)程序因此不會包含在您的功能版本中。要驗證它master確實是超集maint，請使用git log：配方：驗證主控是主線的超集

• git log master..maint這個命令不應(yīng)該列出任何提交。否則，請檢查master并合并maint到它中?，F(xiàn)在可以繼續(xù)創(chuàng)建功能版本。將標(biāo)簽應(yīng)用于master指示發(fā)布版本的提示：配方：發(fā)布標(biāo)簽git tag -s -m "Git X.Y.Z" vX.Y.Z master您需要將新標(biāo)簽推送到公共Git服務(wù)器（請參閱下面的“分布式工作流程”）。這使標(biāo)簽可供其他人跟蹤您的項目。推送也可以觸發(fā)更新后的掛鉤來執(zhí)行與版本相關(guān)的項目，例如構(gòu)建發(fā)布 tarball 和預(yù)先格式化的文檔頁面。類似地，對于維護版本，maint跟蹤要發(fā)布的提交。因此，在上述步驟中只需標(biāo)記和推送，maint而不是master。維護分支管理功能發(fā)布后功能發(fā)布后，您需要管理維護分支機構(gòu)。首先，如果您希望繼續(xù)發(fā)布針對最近發(fā)布的功能發(fā)布的維護修復(fù)，那么您必須創(chuàng)建另一個分支來跟蹤提交對于以前 release.To 做到這一點，當(dāng)前維護分支被復(fù)制到與以前的版本版本號命名的另一個分支（如 MAINT-XY（Z-1 ），其中 XYZ 是當(dāng)前版本）. Recipe：復(fù)制 MAINT

• git branch maint-X.Y.(Z-1) maint的maint分支應(yīng)該現(xiàn)在可以快速轉(zhuǎn)發(fā)到新發(fā)布的代碼，以便可以為當(dāng)前版本追蹤維護修復(fù)：配方：將更新維護更新到新版本

• git checkout maint

• git merge --ff-only master如果合并由于不是快進(jìn)而失敗，那么可能會maint在功能發(fā)布中錯過一些修復(fù)。如果分支的內(nèi)容按上一節(jié)所述進(jìn)行驗證，則不會發(fā)生這種情況。功能發(fā)布后的 next 和 pu 的分支管理功能發(fā)布后，集成分支next可以選擇性地從master使用存活主題的提示進(jìn)行回卷和重新構(gòu)建上next：食譜：倒帶和重建

• git checkout next

• git reset --hard master

• git merge ai/topic_in_next1

• git merge ai/topic_in_next2

• …

這樣做的好處是，歷史next將是清潔的。例如，合并到一些主題next可能最初看起來很有前途，但后來發(fā)現(xiàn)不合要求或不成熟。在這種情況下，這個話題被撤銷了，next但事實仍然存在于它曾經(jīng)合并和恢復(fù)的歷史中。通過重新創(chuàng)建next，您可以將這些主題的另一個化身作為一個干凈的平臺重試，而功能發(fā)布是歷史上的一個很好的一點。

如果你這樣做，那么你應(yīng)該公布一個公告，表明next被重新卷繞和重建。

可以遵循相同的倒帶和重建過程pu。pu如上所述，公告是沒有必要的，因為它是一個不計分支。

分布式工作流程

在最后一節(jié)之后，您應(yīng)該知道如何管理主題。總的來說，你不會是唯一一個從事這個項目的人，所以你將不得不分享你的工作。

粗略地說，有兩個重要的工作流程：合并和補丁。重要的區(qū)別是合并工作流可以傳播完整的歷史記錄，包括合并，而修補程序則不能。這兩個工作流程可以并行使用：在 git.git之中，只有子系統(tǒng)維護人員使用合并工作流程，而其他人都發(fā)送補丁。

請注意，維護者可能會施加限制，例如“拒絕簽名”要求，所有提交包含的提交/補丁都必須遵守。請參閱您的項目文檔以獲取更多信息。

合并工作流程

合并工作流程通過復(fù)制上游和下游之間的分支來工作。上游可以將貢獻(xiàn)合并到官方歷史中; 下游根據(jù)他們的正式歷史工作。

有三個主要工具可以用于此：

• git-push [1] 將您的分支機構(gòu)復(fù)制到遠(yuǎn)程存儲庫，通常是所有相關(guān)方都可以讀取的存儲庫;

• git-fetch [1] 將遠(yuǎn)程分支復(fù)制到您的存儲庫; 和

• git-pull [1] 可以一次完成提取和合并。請注意最后一點。不要not使用git pull，除非你真的想合并遠(yuǎn)程 branch.Getting 改變了容易：配方：推/拉：發(fā)布分支/主題git push <remote> <branch>和告訴大家，在那里他們可以獲取from.You仍然要告訴其他人的手段，如郵件。（Git提供 git-request-pull [1] 向上游維護人員發(fā)送預(yù)格式化的pull請求以簡化此任務(wù)。）如果您只想獲取集成分支的最新副本，保持最新也很容易：配方：推/拉：保持最新使用git fetch <remote>或git remote update以保持最新。然后簡單地將您的主題分支從穩(wěn)定的遙控器中分離出來，如前所述。如果您是維護人員并想要將其他人的主題分支合并到集成分支，他們通常會通過郵件發(fā)送請求。這樣的請求看起來像請從 <url> <branch> 拉出來，在這種情況下，git pull可以一次完成提取和合并，如下所示.Recipe：推/拉：合并遠(yuǎn)程主題git pull <url> <branch>，偶爾維護者在嘗試時可能會遇到合并沖突從下游拉動變化。在這種情況下，他可以要求下游進(jìn)行合并，并自己解決沖突（也許他們會更好地知道如何解決沖突）。這是下游罕見的情況之一should從上游合并。補丁工作流程如果您是以電子郵件的形式向上游發(fā)送更改的貢獻(xiàn)者，則應(yīng)像往常一樣使用主題分支（請參閱上文）。然后使用git-format-patch [1]生成相應(yīng)的電子郵件（強烈推薦通過手動格式化它們，因為它使維護者的生活更容易） .Recipe：format-patch / am： 發(fā)布分支/主題

• git format-patch -M upstream..topic 把它們變成預(yù)先格式化的補丁文件

• git send-email --to=<recipient> <patches>

有關(guān)更多使用說明，請參閱 git-format-patch [1] 和 git-send-email [1] 手冊頁。

如果維護人員告訴您，您的修補程序不再適用于當(dāng)前上游，則必須重新標(biāo)記您的主題（因為無法進(jìn)行格式化修補程序合并，所以無法使用合并）：

教程： format-patch / am： 使主題保持最新

git pull --rebase <url> <branch>

然后，您可以修復(fù)重新綁定期間的沖突。大概你沒有發(fā)布你的主題，除了通過郵件，所以重新發(fā)布它不是問題。

如果您收到這樣的補丁系列（作為維護者，或者作為發(fā)送給它的郵件列表的讀者），將郵件保存到文件，創(chuàng)建新的主題分支并用于git am導(dǎo)入提交：

教程：format-patch / am：導(dǎo)入補丁

git am < patch

值得指出的一個特性是三路合并，如果發(fā)生沖突可以提供幫助：git am -3將使用包含在補丁中的索引信息來計算合并基數(shù)。有關(guān)其他選項，請參閱 git-am [1] 。