增強Github流程的15個技巧

增強Github流程的15個技巧

Posted by Git on 2019-10-14 22:43:00

高質量軟件的屬性有很多：魯棒性，可測試性，彈性，模塊化，可維護性，可用性，安全性，性能，可伸縮性，以及更多取決於所構建應用程序的類型。在本文中，我將主要關注以下特徵：

  • 好的文檔：自述文件，文檔站點和變更日誌。
  • 定義明確的編碼標準和約定。
  • 使用semver進行正確的版本控制。
  • 自動化測試：數量不多，專注於功能性非回歸測試。
  • 開發人員的幸福，當然！

為此，我提出了一個實用的Github流，它利用開放源代碼工具來幫助促進和自動化實現該目標所需的許多任務。

如果您正在開發一個開源項目，則要發布項目Github，這是事實。Git和Github通過分別成為版本控制的實際通用語言和最終的協作場所，從根本上改變了OSS的開發方式。

Github提出的官方工作流程稱為github flow，在其網站guide.github.com/introduction/flow上有很好的記錄，大多數開源項目都遵循這種工作流程，但略有不同。

Github工作流程非常靈活，因為它不會告訴您如何發布和記錄更改，在接受請求請求時使用哪種合併策略，使用哪些工具，要遵循哪些提交標准或要接受哪些審查？拉動請求，這取決於您，這很有意義，因為沒有針對每個團隊需求的通用解決方案。

以下是根據我的經驗提出的建議列表：

我主要（幾乎全部）使用JavaScript工作，我將提到的許多工具都是JS生態系統的一部分，但是這些原理適用於任何語言。

優先考慮您的問題並通過Github項目跟踪進度

2016年9月，“項目”功能啟動。它是使您可以創建看板樣式板以在存儲庫和組織級別組織，確定優先級和跟踪工作的工具。如果您使用Github問題，我強烈建議您利用此功能更好地組織和交流項目的優先級和當前的工作。您可以在以下鏈接help.github.com/articles/tracking-the-progress-of-your-work-with-project-boards上了解更多信息

使用標籤對您的問題進行分類

Github提供了出色的過濾功能。如果您正在開發一個開源項目，則希望人們在您的項目上進行協作，並為使用它的開發人員提供良好的體驗。通過標記您的問題，開發人員將能夠更輕鬆地瀏覽問題列表，節省時間並允許他們以更少的輸入摩擦進行貢獻。

利用Github模板獲取請求和問題

花時間為您的問題編寫Github模板和請求請求肯定會有所收穫；這將迫使或至少幫助開發人員以標準方式報告錯誤並請求功能，以及解決這些錯誤所需的所有信息。

在blog.github.com/2016–02–17-issue-and-pull-request-templates上了解更多

錯誤報告的一些一般準則：

提交問題之前，請檢查您是否已完成以下步驟：

  • 確保您使用的是最新版本
  • 使用搜索功能來確保之前未報告該錯誤

錯誤報告應包含以下信息：

  • 摘要：簡短說明。
  • 重現步驟：您是如何遇到該錯誤的？複製說明。
  • 預期的行為：您如何期望其表現？
  • 實際行為：它的實際行為如何？
  • 參考：鏈接到任何相關票證或信息源。
  • 如果可能，請附上錯誤的直觀文檔。截圖，視頻和/或動畫gif。

拉取請求一般準則：

  • 請確保沒有現有的請求請求試圖解決所提到的問題。
  • 在問題跟踪器上檢查相關問題。
  • 不重要的變化應首先在一個問題上進行討論。
  • 讓我們知道您正在解決此問題。
  • 在主題分支而不是母版中開發。
  • 提供有用的請求請求描述。
  • 遵循項目提交準則。
  • 為您的PR寫一個好的描述。
  • 鏈接至說明中的Github問題。

使用命令行

控制台是您的朋友。根據我的經驗，如果您使用開源技術，那麼從命令行學習與Github交互是您最好的時間利用方式。有許多不錯的GUI，但是沒有一個會給命令行帶來靈活性。還有一些工具可以使生活變得更加簡單，並且效率更高的開發人員只能在命令行中使用：

  • hub是git的命令行包裝，可以使您在GitHub上更好。無論您是開源的初學者還是經驗豐富的貢獻者，Hub都可以從命令行更輕鬆地獲取存儲庫，瀏覽項目頁面，派生存儲庫甚至提交請求請求。hub.github.com
  • tj / git-extras是一組git實用程序，例如repo摘要，repl，changelog填充，作者提交百分比等。github.com/tj/git-extras

遵循嚴格的提交消息標準並進行有範圍的提交

始終為您的項目定義並遵循明確的提交消息標準，一些通用準則是：

  • 將每個修訂作為單獨的更改提交。
  • 提供有用的提交消息。
  • 在第一行中提供簡短的提交消息（50-100個字符）。查看gitk或的輸出git log --oneline可能會幫助您理解原因。
  • 在您的提交消息的主體上引用git問題。

另外，我強烈建議您調整郵件範圍，以更好地生成變更日誌。當您確定消息的範圍時，您的變更日誌可以提供更多信息。AngularJS提交約定和changelog生成是一個很好的示例gist.github.com/stephenparish/9941e89d80e2bc58a153#generating-changelogmd

定義編碼樣式標準並配置預提交掛鉤

定義編碼標準並通過pre-commits掛鉤強制執行，對於編寫可維護的代碼至關重要。通過遵循這些標準，您可以確保所有代碼看起來都是相同的，無論是誰編寫的，都有助於接管和維護其他人編寫的代碼。

我推薦的設置是Prettier和StandardJS，但是，這是一個優先選擇的問題，還有很多其他設置，並且您還可以配置自定義設置，只要您遵循編碼標準，您將受益。

typicode / husky是配置預提交掛鉤的好工具。

配置對拉取請求的自動化測試和檢查

非常需要針對每個拉取請求進行自動功能測試，安全性和代碼樣式檢查，您不希望手動執行此操作。可以快速配置連續集成服務器（例如TravisCI），以在每次提交請求時針對主題分支自動運行這些測試，並且可以配置Github以防止開發人員合併未通過這些測試的請求。如果這些自動化測試失敗，Github將在請求請求中顯示一條消息，供請求者修復它們。

在docs.travis-ci.com/user/pull-requests上了解更多信息

保護您的主分支並要求代碼審查

Github使您可以保護master分支免受直接提交，強制推送和變基的攻擊。在項目上與其他人協作時，這一點非常重要。另外，您需要將代碼檢查作為必需的步驟，以便將代碼合併到母版中。通過在每個存儲庫的“設置”選項卡上進行配置。

通過保護主代碼並強制執行代碼審閱，您可以放心，不希望的代碼不會進入主數據庫，而團隊中的任何人都不會影響其他人修改主git歷史記錄或推送未經審閱的代碼。

壓拉請求

這是一個熱門辯論：合併vs壁球vs重新設基。我認為壁球合併是最好的方法，原因如下：

  • 並非所有的開發人員都知道如何在主服務器上適當地重新構建拉取請求，這是事實。許多開發人員只會在他們的更改之上簡單地合併master。壁球合併消除了那些無用的合併消息，這些消息在以後無法構建變更日誌並為git日誌添加噪音。
  • 並非所有的貢獻者都將遵循提交準則，壁球合併允許控製到達master分支的提交消息。

為了成功遵循壁球合併工作流程，必須將每個拉取請求的範圍限定為特定功能，錯誤修復或雜項。

Semver，Github標籤，發布和自動變更日誌

版本控制在軟件中尤其是在開源項目中非常重要，在開源項目中，很多項目將取決於您的軟件。語義版本控制將使每個人的生活更加輕鬆，因為他們只需通過查看版本號就可以準確知道何時中斷添加的更改，新版本是否包含新功能或錯誤修復。

給定版本號MAJOR.MINOR.PATCH，增加：

  • 當您進行不兼容的API更改時的主要版本，
  • 以向後兼容的方式添加功能時的MINOR版本，以及
  • 進行向後兼容的錯誤修復時的PATCH版本。

可以使用預發布和構建元數據的其他標籤作為MAJOR.MINOR.PATCH格式的擴展名。

除了更改您的package.json版本以外，為每個版本生成一個git標籤也是一個好習慣。

在semver.org上了解更多信息。

常規提交規范建議在提交消息之上引入標準化的輕量級約定。該約定與SemVer相吻合，要求軟件開發人員在提交消息，功能，修補程序和重大更改中進行描述。

通過引入此約定，我們創建了一種通用語言，可以更輕鬆地跨項目邊界調試問題。

傳統的commits.org。

TravisCI可以幫助自動化該過程docs.travis-ci.com/user/deployment/releases

您可能還會發現這些軟件包對dominique-mueller / automatic-release，semantic-release / semantic-release有用。

使用標籤掛鉤自動化部署

不必像建議的Git Flow那樣使用發布分支。您可以從git標籤中獲取部署工件；在該鏈接中，您將了解有關如何使用TravisCI docs.travis-ci.com/user/deployment/heroku將git標籤部署到heroku的更多信息。這很簡單，您只需要將標籤屬性設置為true。您可以使用任何其他CI服務器來完成相同的行為。

對於開發環境，您可以設置鉤子以部署最新的主提交，對於功能環境，可以沒有那麼長的生存分支，可以選擇為每個PR請求提供臨時測試環境，但是，這更加複雜，而且並非真正如此。需要。

在聊天室中設置Github流通道

這是從單個位置跟踪Github存儲庫中的活動的非常方便的方法，與您的團隊進行交流的位置非常理想。這些是在主題空間或幾個主題空間上的簡單通知流。但是您可以在聊天室中做更多的事情，在2013年，Github創造了術語ChatOps，您可以在youtube.com/watch?v=NST3u-GjjFw上了解它。

自動依賴更新

使依賴關係保持最新狀態是一項耗時且重複的任務，非常適合自動化。幸運的是，有許多工具可以通過在具有最新版本的項目中自動創建拉取請求來幫助您保持依賴關係的更新，自動的非回歸測試將針對該拉取請求運行，並且如果通過，則您的代碼將繼續運行通常，一旦合併即可。請注意主要版本更改，請始終仔細檢查。

可以幫助您的幾個工具是greenkeeper.io和david-dm.org

通過擴展增強您的Github UI體驗

開源開發人員已經構建了許多有用的擴展，可以增強您的Github體驗，這是您可能會發現有用的列表。

您可以在GitHub Browser Extensions上看到更多信息。

Kikobeats / awesome-Github提供了更多工具來改善github流程。

持續學習與改進

Github和開源軟件開發實踐正在持續快速發展，通過遵循Github公告並遵循您的社區標準和實踐來了解最新的實踐和工具。youtube上的GitHub Training＆Guides頻道是一個很好的資源。youtube.com/githubguides