名稱

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

概要

git *

描述

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

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

單獨(dú)更改

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

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

管理分支

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

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

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

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

Graduation

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

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

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

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

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

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

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

向上合并

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

規(guī)則：向上合并

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

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

topic branches

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

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

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

規(guī)則：主題分支

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

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

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

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

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

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

• git log master..maint這個(gè)命令不應(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)簽可供其他人跟蹤您的項(xiàng)目。推送也可以觸發(fā)更新后的掛鉤來執(zhí)行與版本相關(guān)的項(xiàng)目，例如構(gòu)建發(fā)布 tarball 和預(yù)先格式化的文檔頁面。類似地，對于維護(hù)版本，maint跟蹤要發(fā)布的提交。因此，在上述步驟中只需標(biāo)記和推送，maint而不是master。維護(hù)分支管理功能發(fā)布后功能發(fā)布后，您需要管理維護(hù)分支機(jī)構(gòu)。首先，如果您希望繼續(xù)發(fā)布針對最近發(fā)布的功能發(fā)布的維護(hù)修復(fù)，那么您必須創(chuàng)建另一個(gè)分支來跟蹤提交對于以前 release.To 做到這一點(diǎn)，當(dāng)前維護(hù)分支被復(fù)制到與以前的版本版本號命名的另一個(gè)分支（如 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)前版本追蹤維護(hù)修復(fù)：配方：將更新維護(hù)更新到新版本

• git checkout maint

• git merge --ff-only master如果合并由于不是快進(jìn)而失敗，那么可能會maint在功能發(fā)布中錯(cuò)過一些修復(fù)。如果分支的內(nèi)容按上一節(jié)所述進(jìn)行驗(yà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)不合要求或不成熟。在這種情況下，這個(gè)話題被撤銷了，next但事實(shí)仍然存在于它曾經(jīng)合并和恢復(fù)的歷史中。通過重新創(chuàng)建next，您可以將這些主題的另一個(gè)化身作為一個(gè)干凈的平臺重試，而功能發(fā)布是歷史上的一個(gè)很好的一點(diǎn)。

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

可以遵循相同的倒帶和重建過程pu。pu如上所述，公告是沒有必要的，因?yàn)樗且粋€(gè)不計(jì)分支。

分布式工作流程

在最后一節(jié)之后，您應(yīng)該知道如何管理主題?？偟膩碚f，你不會是唯一一個(gè)從事這個(gè)項(xiàng)目的人，所以你將不得不分享你的工作。

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

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

合并工作流程

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

有三個(gè)主要工具可以用于此：

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

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

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

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

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

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

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

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

git pull --rebase <url> <branch>

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

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

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

git am < patch

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