讓 Python 帶你進入開源的世界——Git 從入門到與他人協作開發

我認為開源社區中有很多優秀的資源，並且可以幫助進階中的程序員提高編程能力和水平。所以，我發起了《HelloGitHub》月刊，同時開始編寫《讓 Python 帶你進入開源的世界》系列，希望更多的小伙伴加入到開源的社區當中。我個人能力有限，分享的知識都是通過我認真的收集、整理、總結、編寫，如果認為本文還不錯，那就歡迎持續關注，並加入到其中 😁。下面就是正文了：

本篇分為三個階段：領進門（新手）、搜腸刮肚的建議（進階）、后續的個人修行，所以可以根據自身情況通過下面的目錄進行選階段閱讀。

建議： 如果是新手的話，請依次完成每一部分的實踐通過后，再學習下一部分。

目錄

• Git 入門
  • Git 和 GitHub 的關系
  • 實踐
• Git 基本使用規范
• Git 工作流
  • Git 工作流1（非項目內成員）：多用於為 GitHub 上的開源項目貢獻代碼
  • Git 工作流2（項目內成員）：常用用於工作中
  • 編寫優秀的 commit 信息
  • 實踐
• 更多 Git 使用技巧
• 建議收集
• 參考

1. Git 入門

Git 是一個“分布式版本管理工具”，簡單的理解版本管理工具：大家在寫東西的時候都用過“回撤”這個功能，但是回撤只能回撤幾步，假如想要找回我三天之前的修改，光用“回撤”是找不回來的。而“版本管理工具”能記錄每次的修改，只要提交到版本倉庫，你就可以找到之前任何時刻的狀態（文本狀態）。

1.1 Git 和 GitHub 的關系

Git 是一個“分布式版本管理工具”，這里需要理解分布式。也就是每個用戶會有一個本地倉庫，同時還有一個遠程倉庫。而 GitHub 就是用戶遠程倉庫的托管網站。不同用戶可以復制同一個倉庫的代碼到本地，然后開發某一部分功能，完成后提交請求到遠程倉庫。如果合並成功，后面用戶再獲取、更新該遠程倉庫的代碼，就會包含你開發的功能，從而達到多個用戶同時開發不同模塊互不影響的效果。

例如：Gitlab、Bitbucket、自搭建的 Git 服務器等，都是同樣的道理。

由於篇幅問題，我把 GitHub 入門 部分提前寫出來了，可以在后面的實踐部分閱讀。

1.2 實踐

參考我寫的 GitHub 入門教程，還有我推薦的 Git 極簡入門教程

1. GitHub 入門教程：先創建賬號，到第四步在參考下面的教程。
2. Git 極簡入門教程：在上述教程中創建的項目中，練習本教程中的命令，並理解其作用。

練習：

1. 請跟着 GitHub 入門教程 的步驟，創建項目並提交修改。
2. 閱讀 Git 極簡入門教程，創建一個任意分支，並推送到遠程倉庫。
   最后，點擊這里，提交你創建的項目地址。

我會及時給出回復。如果完成了上述步驟並通過，你就可以閱讀下面的章節了。

2. 基本規范

本部分翻譯修改自：project-guidelines

首先，不管是項目的管理者或貢獻者，都需要了解的一些基本規則：

• 從 develop 分支創建新的分支

  原因：

  這樣可以確保 master 分支總是沒有問題的，從而可以直接運行或者發布。同時因為 develop 分支是開發的主分支，可以確保所有子分支都是繼承於同一分支開發。

• 創建 feature 分支開發新的功能

  原因：

  因為這樣所有的工作都是在專用分支（feature）而不是主分支上，使得彼此的工作是完全隔離的。它允許你隨意提交請求而不會影響其他人的開發。你可以實時迭代你開發的功能，即使這些代碼是未完成，也不會污染和影響公共分支。

• 通過 Pull Request 方式提交代碼到 develop 或 master，不要直接 Push

  原因：

  因為 PR 的方式可以通知所有團隊成員你已完成該模塊的功能，還可以輕松地對代碼進 Review，並可以在該 PR 下討論功能和交流。

• 同步本地的 develop 分支到最新，然后通過 rebase 命令合並到你的 feature 分支，最后提交 PR

  原因：

  因為，在 feature 分支上，通過 rebase 命令合並 develop 分支是不會產生額外的 commit（假設沒有沖突），從而可以得到一個干凈整潔的提交歷史。

• 先通過 rebase 命令解決沖突，然后再提交 Pull Request

• 提交通過后刪除本地和遠程的 feature 分支（項目內成員）

  原因：

  因為，分支過多會造成不必要的混亂和重復提交，要記住 feature 分支只存在於開發進行時。

• 在提交 Pull Request 之前，確保你的分支代碼運行沒問題並且通過測試（包括代碼風格檢測）

  原因：

  你將要提交代碼到穩定的分支，如果你的功能分支測試失敗，那么同樣的會導致目標分支運行、測試失敗。與此同時，PR 之前你還需要檢測代碼是否有代碼風格檢測，這樣做的目的是為了讓整個項目的代碼更加易讀、統一。

• 記得設置 .gitignore 文件

  原因：

  有了 .gitignore 文件，就可以把運行過程中或者 ide 產生的並不是項目本身的文件過濾掉。

• 把 develop 和 master 分支設置為保護

  原因：

  它保護你的生產和開發分支免受意外和不可挽回的錯誤。更多現詳情可以閱讀，GitHub 關於 protected 的說明

3. Git 工作流

工作流分為：

1. 工作流1（非項目內成員）：未被邀請進項目，也就無法直接創建分支
2. 工作流2（項目內成員）：已經被邀請進項目，可以直接創建分支

GitHub 上為開源項目提交代碼就用：非項目內成員工作流

工作中大多使用：項目內成員工作流

兩種工作流，相差的並不多，推薦先學習 工作流1。

3.1 Git 工作流1（非項目內成員）

因為不是項目中的成員，無法直接修改項目中的代碼。所以需要先拷貝（Fork）項目到自己的遠程倉庫中（GitHub賬號下），然后基於自己克隆過來的項目開發新的功能，最后提交 PR。

project_url：想要貢獻代碼的項目地址（源地址）
fork_project_url：克隆到自己遠程倉庫的項目地址

• Fork 項目

  項目首頁 "Fork"
  

• 下載項目

  git clone fork_project_url
  

• 增加源項目倉庫地址

  git remote add <origin-name> project_url
  

• 切換到 develop 分支

  git checkout develop
  

• 創建新的 feature或bug-fix 分支

  git checkout -b <branchname>
  

• 保存你的修改（開發、修復bug）

  git add
  git commit -a
  

  原因：

  git commit -a 命令中的 -a 參數是開啟編輯器編輯 commit 信息，會在后面有詳細的說明。

• 更新到與遠程倉庫同步

  git checkout develop
  git pull --rebase <origin-name> develop
  

• 把最新的 develop 分支通過 rebase 命令合並到 feature 分支和對應的遠程分支

  git checkout <branchname>
  git rebase -i --autosquash develop
  

  原因：

  你可以通過 --autosquash 命令把多個 commit 壓縮成一個 commit，這樣是的歷史更加整潔，一個功能就一個commit。通過 rebase 在本地就把沖突解決好，以避免提交 PR 時才發現沖突，導致提交失敗。

• 如果在合並時沒有出現沖突（conflict）就跳過這步；如果有沖突，可以先修改文件中的沖突，然后執行下面的命令。

  git add <file1> <file2> ...
  git rebase --continue
  

• Rebase 命令會修改歷史，所以你 push 時可能會需要加上 -f 強制修改歷史。如果有其他人也在你的分支上開發，就使用 --force-with-lease 減少破壞

  git push -f
  

  原因：

  因為只是修改 feature 分支的歷史，而且每個 feature 是獨立（理論上只有一個人開發），所以在 push 時加上 -f 參數並不會影響其他人的工作。

• 提交 Pull Request

• Pull request 被接受、合並完成，就關閉該評論

• 如上述步驟都已完成，刪除你本地和遠程的 feature 分支

  git branch -d <branchname>
  git push origin --delete <remote-branchname>
  

3.2 Git 工作流2（項目內成員）

這種工作流，更適合用在工作中。

• 下載項目

  git clone project_url
  

• 切換到 develop 分支

  git checkout develop
  

• 創建新的 feature或bug-fix 分支

  git checkout -b <branchname>
  

• 保存你的修改（開發、修復bug）

  git add
  git commit -a
  

  原因：

  git commit -a 命令中的 -a 參數是開啟編輯器（vim基本操作）編輯 commit 信息，會在后面有詳細的說明。

• 更新到與遠程倉庫同步

  git checkout develop
  git pull --rebase
  

• 把最新的 develop 分支通過 rebase 命令合並到 feature 分支和對應的遠程分支

  git checkout <branchname>
  git rebase -i --autosquash develop
  

  原因：

  你可以通過 --autosquash 命令把多個 commit 壓縮成一個 commit，這樣是的歷史更加整潔，一個功能就一個commit。通過 rebase 在本地就把沖突解決好，以避免提交 PR 時才發現沖突，導致提交失敗。

• 如果在合並時沒有出現沖突（conflict）就跳過這步；如果有沖突，可以修改文件中的沖突，然后執行下面的命令。

  git add <file1> <file2> ...
  git rebase --continue
  

• Rebase 命令會修改歷史，所以你 push 時可能會需要加上 -f 強制修改歷史。如果有其他人也在你的分支上開發，就使用 --force-with-lease 減少破壞

  git push -f
  

  原因：

  因為只是修改 feature 分支的歷史，而且每個 feature 是獨立（理論上只有一個人開發），所以在 push 時加上 -f 參數並不會影響其他人的工作。

• 提交 Pull Request

• Pull request 被接受、合並完成，就關閉該評論

• 如上述步驟都已完成，刪除你的本地 feature 分支

  git branch -d <branchname>
  git push origin --delete <remote-branchname>
  

3.3 編寫優秀的 commit 信息

制定良好的創建 commit 規范，並堅持使用，使得與他人合作更容易。下面是一些經驗和建議：

• 把 commit 信息分為 標題和內容兩個部分，兩者之間要有個空行

  原因：

  Git 可將你的提交消息的第一行做為摘要

• 標題控制在 50 個字符以內，內容最多不超過 72 個字符

  原因：

  commit 信息盡可能簡潔和精准

• 標題首字母大寫

• 標題不要有句號

• 標題使用“祈求語句”

• 內容中解釋為什么要有這次提交、如何解決問題、可能影響的地方

  原因：

  如果有需求、issues地址、可以附上。更多詳情

3.4 實踐

本節就一個實踐內容，但是並不是很簡單，請仔細閱讀並遵守：

向我的 test_project 項目的 develop 分支提交一個PR，要求如下：

1. 在 README.md 文件中新啟一行，增加內容為上一個 commit 的 id 號
2. Commit 信息要按照上述 3.3 節要求書寫

提示： 可能會因為接受提交順序而產生沖突，如遇到沖突，要解決完沖突后重新提交。如遇問題，可參考 “4. 更多 Git 使用技巧”。

4. 更多 Git 使用技巧

俗話說：師傅領進門修行靠個人。

用好一個工具或技能最好的方式就是不斷的使用，使用中必然會出現問題。當你解決了足夠多的問題，你也就成為老司機了。

遇到問題：

• 請先閱讀錯誤提示
• 通過搜索引擎尋找答案（國內推薦使用 bing 搜索技術問題）
• 用自己的語言經可能詳細的描述問題，並收集充足的信息后，在詢問老司機

最后，請拿走這本秘籍：git-tips，😄

5. 建議收集

本教程肯定還有不足的地方或者你覺得好的地方，歡迎自由留言積極討論，希望這個系列能夠幫助到更多的小伙伴！

• 本教程不好的地方？
• 是否需要提供視頻教程？
• 零基礎入門是否感覺到吃力？

參考

• project-guidelines
• autosquashing-git-commits
• Git 寫出好的 commit message