version control

GitHub是一個聚集了數百萬開發者的網站，他們每天都在一起合作共同開發開源軟體。GitHub同時也是給軟體使用者報告問題的地方，它托管了數十億行程式碼。作為一個開發者，你應該了解GitHub中最重要的一些功能。 GitHub介紹 為什麼使用GitHub？ GitHub問題 社交式程式碼開發 關注 星標 衍生 熱門=更好 合併請求 專案管理 比較提交 Webhooks和服務 Webhooks 服務 最後一句 GitHub介紹 GitHub是一個網站，每天都有數百萬名開發者在這裡合作共同開發開源軟體。它也是軟體使用者報告問題的地方，同時也是托管數十億行程式碼的地方。 簡而言之，GitHub是一個為開發者打造的平台，並且是基於Git的。 提示：如果你對Git還不熟悉，可以查看這個Git指南。 作為一個開發者，你每天都無法避免使用GitHub，無論是為了托管你的程式碼還是使用別人的程式碼。本文將介紹GitHub的一些重要概念，以及如何使用一些提升你工作流程的功能，以及如何將其他應用程式整合到你的開發過程中。 為什麼使用GitHub？ 現在你已經知道GitHub是什麼，你可能會問你應該為什麼要使用它。 畢竟，GitHub是由一家私人公司管理的，他們從托管別人的程式碼中獲獎利潤。那你為什麼要使用GitHub，而不是類似的平台，如BitBucket或GitLab？ 除了個人喜好和技術原因外，有一個重要的原因：每個人都在使用GitHub，所以它的社群效應非常巨大。 大型程式碼庫過去已經從其他版本控制系統遷移到Git，因為Git在使用上非常方便，而GitHub在Open Source社群中一直處於很好的地位(並且付出了很多努力)。 所以今天，無論你查找任何庫，你99%的機會在GitHub上找到它。 除了Open Source程式碼外，很多開發者也會因為使用GitHub上的獨特功能而在上面託管私有庫。 GitHub問題 GitHub問題是全球最受歡迎的錯誤追蹤工具之一。 它提供了一個使庫的所有者可以組織、標記和分配給里程碑的問題的功能。 如果你在由其他人維護的項目上報告問題，它會保持開放，直到你關閉它(例如，如果你找到了問題)或項目所有者關閉它。 有時你會得到結論性答案，其他時候問題會保持開放，並且會被標記一些資訊以對其進行分類。開發者可能會根據您的反饋修復問題或改進程式碼庫。 大多數開發者並不為他們在GitHub上釋出的程式碼提供支援，所以你不能指望獲得及時的回覆。但有時候開源庫是由提供相關服務的公司發布的，這些公司可能對該程式碼提供相關服務，或提供具有更多功能的商業版本，或者有一個插件架構，它們可以作為有償的開發人員工作在開源軟體上。 社交式程式碼開發 幾年前，GitHub的標誌中包含了「社交式程式碼開發」的標語。 這表示什麼，現在是否仍然相關？當然是相關的。 關注 在GitHub上你可以關注開發者，只需要進入他們的個人資料並點擊「關注」按鈕。 你也可以關注一個庫，只需要點擊庫的「關注」按鈕。 無論哪種情況，這些活動都會顯示在你的主頁上。這裡的「關注」不像Twitter上的「關注」，在這裡你可以看到人們在GitHub上做了哪些事情。 星標 GitHub最重要的功能之一是將庫加入星標。這個動作將庫加入到你的「已加星標庫」列表中，使你可以在以後找到你之前感興趣的項目。這也是其中一種最重要的評級機制，因為一個庫獲得的星星數越多，它就越重要，並且會在搜索結果中更常出現。 重要的項目有時可能會有超過7萬的星標。 GitHub還有一個trending頁面，它會顯示在一段時間內獲得最多星標的庫，例如今天、本週或本月。 進入這些熱門列表會產生其他的社交效應，比如被其他網站推薦，因為你有更多的曝光機會。 衍生 一個項目的最後重要的社交指標是fork的次數。 這也是GitHub的關鍵功能之一，因為衍生(fork)是提交合併請求(PR)的基礎，也是一個變更建議。一個人基於你的庫進行衍生，做出一些變更，然後創建一個合併請求來請求你合併這些變更。 有時候衍生的人永遠不會請求合併任何東西，只是因為他們喜歡你的程式碼，決定在它的基礎上添加一些內容，或者解決了他們遇到的某個 bug。 衍生只是將GitHub項目的文件克隆下來，不會包含原始項目的星標和問題。 熱門=更好 總的來說，這些都是項目受歡迎程度的關鍵指標，通常還與最後提交的日期、作者在問題追蹤器中的參與度一起使用，這些都是評估你是否可以依賴一個庫或軟體的有用指標。 合併請求 在介紹**什麼是合併請求(PR)**之前，我們先來看看是如何進行的。 通常，一個人會基於你的庫進行衍生(fork)，做出一些變更，然後創建一個合併請求(PR)來請求你合併這些變更。 一個項目可能會有數百個合併請求，一般而言，一個項目越受歡迎，合併請求越多，就像React項目一樣： 一旦一個人提交了一個合併請求，使用GitHub界面很容易，該合併請求需要項目的核心維護者進行審查。 根據你的合併請求的範圍(變更數量、受到變更影響的事物數量、觸及的程式碼的複雜度)維護者可能需要多一點或少一點的時間來確保你的變更與該項目兼容。 一個項目可能會有明確的時間表，他們希望推出一些新的更改。當你在PR中說明了一個復雜的架構時，維護者可能希望保持事情簡單。 這可能意味著不是所有的合併請求都會被迅速接受，也不能保證合併請求會被接受。 就像我在上面發布的例子中，有一個在該庫中已經有一年半的合併請求。這在所有的項目中都會發生。 專案管理 除了問題跟蹤，GitHub界面還提供了其他旨在幫助專案管理的功能。 其中之一是項目(Project)。這在生態系統中非常新，並且使用非常罕見，但它是一個看板工具，有助於組織問題和待完成的工作。 維基(Wiki)旨在用於用戶文檔。到目前為止，我看到的使用Wiki最令人印象深刻的是Go Programming Language GitHub Wiki。...

我在项目中使用 Git 作为版本控制工具，并且经常遵循以下策略。 这个策略受到了A successful Git branching model的启发。 我有两个永久分支：master和develop。 以下是我日常开发中遵循的规则： 当我接手一个新任务或决定加入一个功能时，有两条主要路径： 如果功能较为简单，或后续提交不会破坏代码（至少我希望如此）：我可以在develop分支上提交，或者创建一个快速功能分支，然后将其合并到develop分支上。 如果功能需要进行多次提交才能完成，可能需要花费几天时间提交才能使功能恢复稳定的状态：我会创建一个功能分支，然后将其合并到develop分支上。 如果我们的生产服务器需要立即采取措施，比如需要尽快解决的 bug 修复，我会创建一个短期修复分支，解决问题后在本地和测试机上进行测试，然后将其合并到 master 和 develop 分支上。 如果我需要在生产服务器上快速推送一个功能或修改，并且 develop 分支中代码不稳定，我希望尽快得到该功能或修改：我可以跳过 develop 分支，创建一个快速功能分支并将其合并到 master 和 develop 分支上，只要这个功能或修改是快速且简单的。如果在后续过程中发现这是一个更复杂的问题，最好等待并稳定 develop 分支上的代码。 develop 分支会一直处于不稳定状态，所以在准备发布时，需要将其放入“冻结”状态。代码经过测试，所有工作流程都经过验证，准备将其合并到 master 分支上。 每次将 develop 或其他短期修复分支合并到 master 分支时，我都会使用版本号做标签，这样如果出现问题可以轻松回滚到先前的状态。

我每天都使用 Git，過去我曾寫過一篇 Git 指南 和一份 Git Cheat Sheet。 我自認為是一名 Git 的愛好者，但……我不是一個 Git 專家。 提交、抓取遠程庫、拉取遠程庫、推送到遠程庫……這是我每天使用 Git 的日常事務。 儘管如此，我還是會用一些 Git 的進階功能： Git 能做的進階操作讓我感到驚訝。它可以非常複雜，但我傾向於避免複雜的操作。我幾乎從不使用命令行工具進行 Git 操作，而是使用 GitHub Desktop，這是迄今為止最簡單和最好用的 Git 客戶端。 然而，有兩個功能我有時會使用，分別是 cherry-picking 和合併提交記錄。 讓我們來談談這兩個功能。 在只有我一個開發者的項目中（也就是所有我個人的項目），我往往傾向於直接在主分支（master）上進行工作。例如，如果我只是進行一個簡單的更改，或者向博客添加一篇新文章。這些都是快速且不會破壞原有功能的工作。 但在某些情況下，我並不使用這種方式，而是為一個大的功能創建一個分支。 這在團隊或者開源項目中也是默認的方式。 你創建一個分支，並且經常提交。早期和頻繁地提交有很大的優勢，因為你可以有信心地在代碼上進行工作，知道你總能回到一個正常的狀態，或者至少回到你知道某些東西是正常的之前的狀態。 你可能會進行一系列快速的提交，其中的提交信息可能是“ok”，“試驗這個”，或者“修復愚蠢的錯誤”。 但是在某個時候，你需要收斂到一個穩定的狀態，將更改提交回主分支（master）或任何你想合併的分支。 在那之前，你需要做一件事情：合併（squashing）你的提交記錄。 在 Github 中，當你合併一個 Pull Request 時，它可以自動為你合併提交記錄。這是我過去在公開的開源項目中使用得非常多的工作流程。你只會看到一個提交，而不是在 Pull Request 中包含的所有獨立提交。在 PR 合併過程中，你可以編寫詳細的提交訊息和說明。 這將消除所有與你要合併的分支的頭部（head）不一致的前一個 Git 提交記錄，也將刪除那些可能撤消更改的提交記錄等等。 這就是 Github PR 流程中的合併（squashing）。你也可以在 Github 之外進行合併（squashing）。 一旦你在一個分支上的工作完成，你將 master（或任何你想要合併的分支）合併進來： git merge master 這樣你可以解決任何更新衝突。 然後你切換到 master 分支，並運行以下命令： git merge --squash <你的功能分支> 然後執行...

使用 Homebrew 安裝舊版本的某個套件可能比你預期的要複雜一些 我遇到了這個問題：我更新了我使用的 CMS - Hugo，其中一個比我使用的版本更新的版本引入了一個破壞性的變更。 我的首頁不再列出博客文章了。我沒有時間弄清楚為什麼，所以我說：“我只需回滾”。 現在的問題變成了.. “怎麼辦？” 首先，我卸載了 Hugo： brew unlink hugo 然後我按照我在這篇文章中找到的指示進行操作。我需要搜索 Hugo 套件公式https://github.com/Homebrew/homebrew-core/search?utf8=%E2%9C%93&q=hugo&type= 然後點擊該文件（Formula/hugo.rb），並點擊History按鈕以查看所有先前的版本。 我找到了我想要的 0.53 版本，並點擊<>按鈕以查看該時間點上的homebrew-core 存儲庫。然後我打開了 Formula/hugo.rb 文件，並點擊Raw以獲取該文件的直接 URL。 然後，我把它用作 brew install 的參數。例如： brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/5441fa16872c9a56bd5997558df45b808f13285b/Formula/hugo.rb 就這樣。 解決我的問題的下一步是卸載當前安裝的版本，並嘗試逐個更新版本，這樣我就可以找出引入了導致問題的變更的發佈版。

我有這個需求。我想要創建一個現有網站的完全複製品，並將其放在一個子域名下，作為存檔。 現在這個網站已經使用版本控制，我想要保留 Git 的歷史記錄，但也想要將其部署到一個新的 GitHub 倉庫，這樣我就可以將它們分開部署了，現在兩個網站可以各自有自己的命運。 這個網站是一個 Hugo 網站，所以我只需將網站文件夾複製到另外一個文件夾中即可，這樣在本地完成了。 然後我進入複製後的網站文件夾，在終端中運行以下命令： git remote -v 這將列出現有的 GitHub 倉庫作為「origin」遠端倉庫。 然後我運行： git remote rm origin 這將刪除 origin 遠端倉庫，這樣運行 git remote -v 將不再返回任何結果。 現在，由於我使用 GitHub Desktop，我只需將該文件夾拖放到該應用程序中，然後就能從那裡創建一個新的、不同的 GitHub 倉庫了。

這是一個很好的問題。有利有弊。我討論這個話題，讓您可以對此做出自己的意見。 應該在 Git 中提交 node_modules 文件夾嗎？ 我提到了 Git，但同樣的原則也適用於您所使用的任何版本控制系統。 這是一個很好的問題。有利有弊。 我建議的默認選擇是不提交 node_modules 文件夾，而是將其添加到您的.gitignore文件中。 您可能有特殊的需求，反過來改變這個決定。 我討論這個話題，讓您可以對此做出自己的意見。 以下是不提交 node_modules 的一些論點： 您可以保持 Git 歷史純淨。當您添加新的套件時，您只需存儲package.json和package-lock.json文件的更改。當您決定更新套件版本時，只需存儲package-lock.json的文件更改。 package-lock.json是 npm 的一個相對較新的功能，它取代了以前使用的“shrinkwrap”命令。 您避免將數百MB的依賴項放入您的存儲庫中，這意味著隨著時間的推移，工作速度將更快。切換分支和檢出代碼是受存儲庫大小影響很大的2個操作。 在使用分支時，您可能會遇到超出您的代碼範圍的合併衝突，而是涉及依賴代碼。這對您處理來說並不好，可能會浪費很多時間。避免提交更改依賴項後的合併請求或合併操作，將有更多的文件涉及到這個過程。工具變得更慢，甚至可能決定不顯示完整的差異（例如 GitHub）。 如果您在部署到與開發機器不同的平台時（常見情況是在 Mac 上開發，在 Linux 上部署），需要重新編譯原生的 Node 模塊。您需要調用npm rebuild，這會使服務器與開發機器不同步。 不提交 node_modules 意味著您需要將所有模塊列在package.json（和package-lock.json）中，這是必須的步驟。這很好，因為您可能不會很注意這樣做，如果您不這樣做，某些 npm 操作可能會出錯。 提示：在package.json文件中不需要使用具體版本，自從引入了package-lock.json文件以後不再需要了。 如果您使用單獨的dependencies和devDependencies集合，通過提交node_modules文件夾，您基本上提交了devDependencies，而生產構建無法（輕易）去除它們。 可能會導致您提交 node_modules 的原因，以及如何解決它們： npm套件可能被其作者從 npm 注冊表中刪除。在 2016 年發生過著名的left-pad事件（了解更多）。這在受歡迎的套件中非常少見。如果發生這種情況，您可能無法再使用那個特定的功能。 您還可以主張npm不能保證無限期存在，它可能會消失，所以確保將完整的代碼與您的應用程序一起提交，是確保將來擁有的一種簡單方法。 每次使用套件時，在 GitHub 上創建一個 fork。偶爾保持它與原始庫同步（可以自動化）。 這在某些情況下並不實用，因為套件可能有數十個它們自己的依賴項。 您可以為項目使用私有存儲庫服務器，並將其用於托管所有依賴項。 選項包括： sinopia npm_lazy npm-lazy-mirror artifactory npm Enterprise（來自 npm 公司） 提交依賴項的另一個原因是能夠快速編輯代碼，如果您發現錯誤或者想要向庫添加某些內容。 這是一把雙刃劍：如果這樣做，您就失去了升級套件的能力，如果有新版本發布，這只對於快速的臨時修復有好處。 最佳的解決方案是要麼向原始項目提交要求的 PR，要麼 fork 它並將您的 fork 用作依賴項。