diff options
Diffstat (limited to 'Documentation/translations/zh_TW/process/7.AdvancedTopics.rst')
-rw-r--r-- | Documentation/translations/zh_TW/process/7.AdvancedTopics.rst | 56 |
1 files changed, 28 insertions, 28 deletions
diff --git a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst index 2cbd16bfed29..db74d8ca3f3b 100644 --- a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst +++ b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst @@ -24,14 +24,14 @@ 使用Git管理補丁 --------------- -內核使用分布式版本控制始於2002年初,當時Linus首次開始使用專有的Bitkeeper應用 -程序。雖然BitKeeper存在爭議,但它所體現的軟體版本管理方法卻肯定不是。分布式 +內核使用分佈式版本控制始於2002年初,當時Linus首次開始使用專有的Bitkeeper應用 +程序。雖然BitKeeper存在爭議,但它所體現的軟件版本管理方法卻肯定不是。分佈式 版本控制可以立即加速內核開發項目。現在有好幾種免費的BitKeeper替代品。 但無論好壞,內核項目都已經選擇了Git作爲其工具。 -使用Git管理補丁可以使開發人員的生活更加輕鬆,尤其是隨著補丁數量的增長。Git也 +使用Git管理補丁可以使開發人員的生活更加輕鬆,尤其是隨着補丁數量的增長。Git也 有其粗糙的邊角和一定的危險性,它是一個年輕和強大的工具,仍然在其開發人員完善 -中。本文檔不會試圖教會讀者如何使用git;這會是個巨長的文檔。相反,這裡的重點 +中。本文檔不會試圖教會讀者如何使用git;這會是個巨長的文檔。相反,這裏的重點 將是Git如何特別適合內核開發過程。想要加快用Git速度的開發人員可以在以下網站上 找到更多信息: @@ -42,22 +42,22 @@ 同時網上也能找到各種各樣的教程。 在嘗試使用它生成補丁供他人使用之前,第一要務是閱讀上述網頁,對Git的工作方式 -有一個紮實的了解。使用Git的開發人員應能進行拉取主線存儲庫的副本,查詢修訂 -歷史,提交對樹的更改,使用分支等操作。了解Git用於重寫歷史的工具(如rebase) -也很有用。Git有自己的術語和概念;Git的新用戶應該了解引用、遠程分支、索引、 -快進合併、推拉、游離頭等。一開始可能有點嚇人,但這些概念不難通過一點學習來 +有一個紮實的瞭解。使用Git的開發人員應能進行拉取主線存儲庫的副本,查詢修訂 +歷史,提交對樹的更改,使用分支等操作。瞭解Git用於重寫歷史的工具(如rebase) +也很有用。Git有自己的術語和概念;Git的新用戶應該瞭解引用、遠程分支、索引、 +快進合併、推拉、遊離頭等。一開始可能有點嚇人,但這些概念不難通過一點學習來 理解。 使用git生成通過電子郵件提交的補丁是提高速度的一個很好的練習。 -當您準備好開始建立Git樹供其他人查看時,無疑需要一個可以從中拉取的伺服器。 -如果您有一個可以訪問網際網路的系統,那麼使用git-daemon設置這樣的伺服器相對 +當您準備好開始建立Git樹供其他人查看時,無疑需要一個可以從中拉取的服務器。 +如果您有一個可以訪問因特網的系統,那麼使用git-daemon設置這樣的服務器相對 簡單。同時,免費的公共託管網站(例如github)也開始出現在網絡上。成熟的開發 人員可以在kernel.org上獲得一個帳戶,但這些帳戶並不容易得到;更多有關信息, 請參閱 https://kernel.org/faq/ 。 -正常的Git工作流程涉及到許多分支的使用。每一條開發線都可以分爲單獨的「主題 -分支」,並獨立維護。Git的分支很容易使用,沒有理由不使用它們。而且,在任何 +正常的Git工作流程涉及到許多分支的使用。每一條開發線都可以分爲單獨的“主題 +分支”,並獨立維護。Git的分支很容易使用,沒有理由不使用它們。而且,在任何 情況下,您都不應該在任何您打算讓其他人從中拉取的分支中進行開發。應該小心地 創建公開可用的分支;當開發分支處於完整狀態並已準備好時(而不是之前)才合併 開發分支的補丁。 @@ -72,10 +72,10 @@ Git提供了一些強大的工具,可以讓您重寫開發歷史。一個不 簡單癡迷。重寫歷史將重寫該歷史中包含的更改,將經過測試(希望如此)的內核樹 變爲未經測試的內核樹。除此之外,如果開發人員沒有共享項目歷史,他們就無法 輕鬆地協作;如果您重寫了其他開發人員拉入他們存儲庫的歷史,您將使這些開發 -人員的生活更加困難。因此,這裡有一個簡單的經驗法則:被導出到其他地方的歷史 +人員的生活更加困難。因此,這裏有一個簡單的經驗法則:被導出到其他地方的歷史 在此後通常被認爲是不可變的。 -因此,一旦將一組更改推送到公開可用的伺服器上,就不應該重寫這些更改。如果您 +因此,一旦將一組更改推送到公開可用的服務器上,就不應該重寫這些更改。如果您 嘗試強制進行無法快進合併的更改(即不共享同一歷史記錄的更改),Git將嘗試強制 執行此規則。這可能覆蓋檢查,有時甚至需要重寫導出的樹。在樹之間移動變更集以 避免linux-next中的衝突就是一個例子。但這種行爲應該是罕見的。這就是爲什麼 @@ -86,9 +86,9 @@ Git提供了一些強大的工具,可以讓您重寫開發歷史。一個不 對於一個私有的分支,rebasing 可能是一個很容易跟上另一棵樹的方法,但是一旦 一棵樹被導出到外界,rebasing就不可取了。一旦發生這種情況,就必須進行完全 合併(merge)。合併有時是很有意義的,但是過於頻繁的合併會不必要地擾亂歷史。 -在這種情況下建議的做法是不要頻繁合併,通常只在特定的發布點(如主線-rc發布) +在這種情況下建議的做法是不要頻繁合併,通常只在特定的發佈點(如主線-rc發佈) 合併。如果您對特定的更改感到緊張,則可以始終在私有分支中執行測試合併。在 -這種情況下,git「rerere」工具很有用;它能記住合併衝突是如何解決的,這樣您 +這種情況下,git“rerere”工具很有用;它能記住合併衝突是如何解決的,這樣您 就不必重複相同的工作。 關於Git這樣的工具的一個最大的反覆抱怨是:補丁從一個存儲庫到另一個存儲庫的 @@ -98,36 +98,36 @@ Git提供了一些強大的工具,可以讓您重寫開發歷史。一個不 :: - 你可以給我發補丁,但當我從你那裡拉取一個Git補丁時,我需要知道你清楚 + 你可以給我發補丁,但當我從你那裏拉取一個Git補丁時,我需要知道你清楚 自己在做什麼,我需要能夠相信事情而 *無需* 手動檢查每個單獨的更改。 (http://lwn.net/Articles/224135/)。 -爲了避免這種情況,請確保給定分支中的所有補丁都與相關主題緊密相關;「驅動程序 -修復」分支不應更改核心內存管理代碼。而且,最重要的是,不要使用Git樹來繞過 -審查過程。不時的將樹的摘要發布到相關的列表中,在合適時候請求linux-next中 +爲了避免這種情況,請確保給定分支中的所有補丁都與相關主題緊密相關;“驅動程序 +修復”分支不應更改核心內存管理代碼。而且,最重要的是,不要使用Git樹來繞過 +審查過程。不時的將樹的摘要發佈到相關的列表中,在合適時候請求linux-next中 包含該樹。 如果其他人開始發送補丁以包含到您的樹中,不要忘記審閱它們。還要確保您維護正確 -的作者信息; git 「am」工具在這方面做得最好,但是如果補丁通過第三方轉發給您, -您可能需要在補丁中添加「From:」行。 +的作者信息; git “am”工具在這方面做得最好,但是如果補丁通過第三方轉發給您, +您可能需要在補丁中添加“From:”行。 請求拉取時,請務必提供所有相關信息:樹的位置、要拉取的分支以及拉取將導致的 更改。在這方面 git request-pull 命令非常有用;它將按照其他開發人員所期望的 -格式化請求,並檢查以確保您已記得將這些更改推送到公共伺服器。 +格式化請求,並檢查以確保您已記得將這些更改推送到公共服務器。 審閱補丁 -------- -一些讀者顯然會反對將本節與「高級主題」放在一起,因爲即使是剛開始的內核開發人員 -也應該審閱補丁。當然,沒有比查看其他人發布的代碼更好的方法來學習如何在內核環境 +一些讀者顯然會反對將本節與“高級主題”放在一起,因爲即使是剛開始的內核開發人員 +也應該審閱補丁。當然,沒有比查看其他人發佈的代碼更好的方法來學習如何在內核環境 中編程了。此外,審閱者永遠供不應求;通過審閱代碼,您可以對整個流程做出重大貢獻。 審查代碼可能是一副令人生畏的圖景,特別是對一個新的內核開發人員來說,他們 -可能會對公開詢問代碼感到緊張,而這些代碼是由那些有更多經驗的人發布的。不過, +可能會對公開詢問代碼感到緊張,而這些代碼是由那些有更多經驗的人發佈的。不過, 即使是最有經驗的開發人員編寫的代碼也可以得到改進。也許對(所有)審閱者最好 -的建議是:把審閱評論當成問題而不是批評。詢問「在這條路徑中如何釋放鎖?」 -總是比說「這裡的鎖是錯誤的」更好。 +的建議是:把審閱評論當成問題而不是批評。詢問“在這條路徑中如何釋放鎖?” +總是比說“這裏的鎖是錯誤的”更好。 不同的開發人員將從不同的角度審查代碼。部分人會主要關注代碼風格以及代碼行是 否有尾隨空格。其他人會主要關注補丁作爲一個整體實現的變更是否對內核有好處。 |