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

讓 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 項目
  sh 項目首頁 "Fork"
• 下載項目
  sh git clone fork_project_url
• 增長源項目倉庫地址
  sh git remote add <origin-name> project_url
• 切換到 develop 分支
  sh git checkout develop
• 建立新的 feature或bug-fix 分支
  sh git checkout -b <branchname>

• 保存你的修改（開發、修復bug）
  sh git add git commit -a
  緣由：

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

• 更新到與遠程倉庫同步
  sh git checkout develop git pull --rebase <origin-name> develop

• 把最新的 develop 分支經過 rebase 命令合併到 feature 分支和對應的遠程分支
  sh git checkout <branchname> git rebase -i --autosquash develop

  緣由：

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

• 若是在合併時沒有出現衝突（conflict）就跳過這步；若是有衝突，能夠先修改文件中的衝突，而後執行下面的命令。
  sh git add <file1> <file2> ... git rebase --continue

• Rebase 命令會修改歷史，因此你 push 時可能會須要加上 -f 強制修改歷史。若是有其餘人也在你的分支上開發，就使用 --force-with-lease 減小破壞
  sh 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（項目內成員）

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

• 下載項目
  sh git clone project_url
• 切換到 develop 分支
  sh git checkout develop
• 建立新的 feature或bug-fix 分支
  sh git checkout -b <branchname>

• 保存你的修改（開發、修復bug）
  sh git add git commit -a
  緣由：

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

• 更新到與遠程倉庫同步
  sh git checkout develop git pull --rebase

• 把最新的 develop 分支經過 rebase 命令合併到 feature 分支和對應的遠程分支
  sh git checkout <branchname> git rebase -i --autosquash develop

  緣由：

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

• 若是在合併時沒有出現衝突（conflict）就跳過這步；若是有衝突，能夠修改文件中的衝突，而後執行下面的命令。
  sh git add <file1> <file2> ... git rebase --continue

• Rebase 命令會修改歷史，因此你 push 時可能會須要加上 -f 強制修改歷史。若是有其餘人也在你的分支上開發，就使用 --force-with-lease 減小破壞
  sh git push -f

  緣由：

  由於只是修改 feature 分支的歷史，並且每一個 feature 是獨立（理論上只有一我的開發），因此在 push 時加上 -f 參數並不會影響其餘人的工做。

• 提交 Pull Request
• Pull request 被接受、合併完成，就關閉該評論

• 如上述步驟都已完成，刪除你的本地 feature 分支
  sh 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