【翻譯】瞭解 Github 工做流

GitHub 工做流是一個輕量級的、基於分支的工做流，支持實行按期進行部署計劃的團隊和項目。本指南解釋了 GitHub 工做流的工做方式和緣由。

建立一個分支

當你在作一個項目的時候，你會有一堆不一樣的功能或想法，它們可能出如今任什麼時候候——有些已經準備好了，有些尚未。分支的存在能夠幫助您管理此工做流。

當您在項目中建立分支時，您正在建立一個能夠嘗試新想法的環境。您對分支所作的更改不會影響 main 分支，所以您能夠自由地進行實驗並提交更改，由於您的分支不會被合併，直到它準備好供您的合做夥伴審閱。

建議：

分支是 Git 的核心概念，整個 GitHub 工做流都基於它。只有一條規則：主分支中的任何內容都是可部署的。

所以，在處理功能或修復時，在 main 以外建立新分支是很是重要的。你的分支名稱應該是描述性的（例如：refactor-authentication、user-content-cache-key 或者是 make-retina-avatars），以便其餘人看到正在進行的工做。

提交變動

建立分支後就能夠開始進行更改了。不管什麼時候添加、編輯或刪除文件，都會在提交到分支中。提交變動的這個過程能夠在處理功能分支時跟蹤您的進度。

提交還能夠建立一個透明的工做歷史（Commit History），讓其餘人能夠了解你作了什麼以及爲何這麼作。每一個提交都有一個關聯的提交消息（Commit Message），它能夠說明爲何要進行特定更改。此外，每一個提交都被視爲一個單獨的更改單元。若是發現了 bug 或者決定轉向另外一個方向，這可讓您回滾更改。

建議：

提交消息很重要，特別是由於 Git 跟蹤您的更改，而後在將更改推送到服務器後將其展現。經過編寫清晰的提交消息，您可讓其餘人更容易跟進並提供反饋。

打開拉取請求

Pull Request 會啓動關於您的提交的討論。由於它們與底層 Git 存儲庫緊密集成，因此任何人均可以看到若是他們接受您的請求，將會合並哪些更改。

您能夠在開發過程當中的任什麼時候候打開 Pull Request：當您幾乎沒有代碼但想要共享一些屏幕截圖或通常想法時、當您陷入困境須要幫助或建議時、或者當您準備好讓別人審閱您的工做時。經過在 Pull Request 消息中使用GitHub 的 @ 說起系統，您能夠請求特定人員或團隊的反饋，不管他們 down the hall 仍是十個時區以外。

建議：

Pull Request 對於開源項目和管理共享存儲庫的更改很是有用。若是您使用的是 Fork & Pull 模型，Pull Request 提供了一種通知項目維護人員關於您但願他們考慮的更改的方法。若是您使用的是共享存儲庫模型，那麼 Pull Request 有助於在建議的更改合併到主分支以前啓動代碼檢查和對話。

討論並檢查代碼

打開 Pull Request 後，審閱您的更改的人員或團隊可能會有問題或意見。也許編碼風格與項目指南不匹配，更改缺乏單元測試，或者一切看起來都很好。Pull Request 鼓勵這種類型的交流。

您還能夠根據有關您的提交的討論和反饋繼續向您的分支推動。若是有人說你忘了作什麼，或者代碼中有一個 bug，你能夠在你的分支中修復它，並推送（Push）修改。GitHub 將在統一的 Pull Request 視圖中顯示您的新提交以及您可能收到的任何其餘反饋。

建議：

Pull Request 的評論是用 Markdown 編寫的，所以您能夠嵌入圖像和 emoji、使用預格式化的文本塊和其餘輕量級格式。

部署

使用 GitHub，您能夠從分支進行部署，以便在合併（Merge）到主分支以前在生產環境中進行最終測試。

一旦您的 Pull Request 被審查且分支經過了您的測試，您就能夠部署您的更改以在生產中驗證它們。若是您的分支致使了問題，您能夠經過將現有的主分支部署到生產中來回滾它。

不一樣的團隊可能有不一樣的部署策略。對於一些人來講，最好是部署到一個專門配置的測試環境中。對於其餘人來講，基於工做流中的其餘元素，直接部署到生產環境多是更好的選擇。

合併

如今您的更改已經在生產中獲得驗證，如今是時候將代碼合併到主分支中了。

合併後，Pull Request 將保留對代碼的歷史更改的記錄。所以歷史記錄是可搜索的，任何人都能及時回到過去，瞭解爲何以及如何作出決定。

建議：

經過將某些關鍵字合併到 Pull Request 的文本中，能夠將問題與代碼關聯起來。合併 Pull Request 時，也會關閉相關議題。例如，輸入短語 Closes#32 將關閉存儲庫中的第 32 號議題。有關更多信息，請查看咱們的幫助文章。