讓 Python 帶你進(jìn)入開源的世界——Git 從入門到與他人協(xié)作開發(fā)

發(fā)布時(shí)間：2017年07月25日作者： IT網(wǎng)絡(luò)文摘 (該文來自筆記，點(diǎn)擊查看原文)

我認(rèn)為開源社區(qū)中有很多優(yōu)秀的資源，并且可以幫助進(jìn)階中的程序員提高編程能力和水平。所以，我發(fā)起了《HelloGitHub》月刊，同時(shí)開始編寫《讓 Python 帶你進(jìn)入開源的世界》系列，希望更多的小伙伴加入到開源的社區(qū)當(dāng)中。我個(gè)人能力有限，分享的知識(shí)都是通過我認(rèn)真的收集、整理、總結(jié)、編寫，如果認(rèn)為本文還不錯(cuò)，那就歡迎持續(xù)關(guān)注，并加入到其中 ??。下面就是正文了：

大數(shù)據(jù)培訓(xùn),云培訓(xùn),數(shù)據(jù)挖掘培訓(xùn),云計(jì)算培訓(xùn),高端軟件開發(fā)培訓(xùn),項(xiàng)目經(jīng)理培訓(xùn)

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

建議： 如果是新手的話，請(qǐng)依次完成每一部分的實(shí)踐通過后，再學(xué)習(xí)下一部分。

1. Git 入門

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

1.1 Git 和 GitHub 的關(guān)系

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

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

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

1.2 實(shí)踐

參考我寫的 GitHub 入門教程，還有我推薦的 Git 極簡(jiǎn)入門教程

GitHub 入門教程：先創(chuàng)建賬號(hào)，到第四步在參考下面的教程。
Git 極簡(jiǎn)入門教程：在上述教程中創(chuàng)建的項(xiàng)目中，練習(xí)本教程中的命令，并理解其作用。

練習(xí)：

請(qǐng)跟著 GitHub 入門教程 的步驟，創(chuàng)建項(xiàng)目并提交修改。
閱讀 Git 極簡(jiǎn)入門教程，創(chuàng)建一個(gè)任意分支，并推送到遠(yuǎn)程倉庫。
最后，點(diǎn)擊這里，提交你創(chuàng)建的項(xiàng)目地址。

我會(huì)及時(shí)給出回復(fù)。如果完成了上述步驟并通過，你就可以閱讀下面的章節(jié)了。

2. 基本規(guī)范

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

首先，不管是項(xiàng)目的管理者或貢獻(xiàn)者，都需要了解的一些基本規(guī)則：

從 develop 分支創(chuàng)建新的分支
原因：
這樣可以確保 master 分支總是沒有問題的，從而可以直接運(yùn)行或者發(fā)布。同時(shí)因?yàn)?develop 分支是開發(fā)的主分支，可以確保所有子分支都是繼承于同一分支開發(fā)。
創(chuàng)建 feature 分支開發(fā)新的功能
原因：
因?yàn)檫@樣所有的工作都是在專用分支（feature）而不是主分支上，使得彼此的工作是完全隔離的。它允許你隨意提交請(qǐng)求而不會(huì)影響其他人的開發(fā)。你可以實(shí)時(shí)迭代你開發(fā)的功能，即使這些代碼是未完成，也不會(huì)污染和影響公共分支。
通過 Pull Request 方式提交代碼到 develop 或 master，不要直接 Push
原因：
因?yàn)?PR 的方式可以通知所有團(tuán)隊(duì)成員你已完成該模塊的功能，還可以輕松地對(duì)代碼進(jìn) Review，并可以在該 PR 下討論功能和交流。
同步本地的 develop 分支到最新，然后通過 rebase 命令合并到你的 feature 分支，最后提交 PR
原因：
因?yàn)椋?nbsp;feature 分支上，通過 rebase 命令合并 develop 分支是不會(huì)產(chǎn)生額外的 commit（假設(shè)沒有沖突），從而可以得到一個(gè)干凈整潔的提交歷史。
先通過 rebase 命令解決沖突，然后再提交 Pull Request
提交通過后刪除本地和遠(yuǎn)程的 feature 分支（項(xiàng)目?jī)?nèi)成員）
原因：
因?yàn)椋种н^多會(huì)造成不必要的混亂和重復(fù)提交，要記住 feature 分支只存在于開發(fā)進(jìn)行時(shí)。
在提交 Pull Request 之前，確保你的分支代碼運(yùn)行沒問題并且通過測(cè)試（包括代碼風(fēng)格檢測(cè)）
原因：
你將要提交代碼到穩(wěn)定的分支，如果你的功能分支測(cè)試失敗，那么同樣的會(huì)導(dǎo)致目標(biāo)分支運(yùn)行、測(cè)試失敗。與此同時(shí)，PR 之前你還需要檢測(cè)代碼是否有代碼風(fēng)格檢測(cè)，這樣做的目的是為了讓整個(gè)項(xiàng)目的代碼更加易讀、統(tǒng)一。
記得設(shè)置 .gitignore 文件
原因：
有了 .gitignore 文件，就可以把運(yùn)行過程中或者 ide 產(chǎn)生的并不是項(xiàng)目本身的文件過濾掉。
把 develop 和 master 分支設(shè)置為保護(hù)
原因：
它保護(hù)你的生產(chǎn)和開發(fā)分支免受意外和不可挽回的錯(cuò)誤。更多現(xiàn)詳情可以閱讀，GitHub 關(guān)于 protected 的說明

3. Git 工作流

工作流分為：

工作流1（非項(xiàng)目?jī)?nèi)成員）：未被邀請(qǐng)進(jìn)項(xiàng)目，也就無法直接創(chuàng)建分支
工作流2（項(xiàng)目?jī)?nèi)成員）：已經(jīng)被邀請(qǐng)進(jìn)項(xiàng)目，可以直接創(chuàng)建分支

GitHub 上為開源項(xiàng)目提交代碼就用：非項(xiàng)目?jī)?nèi)成員工作流

工作中大多使用：項(xiàng)目?jī)?nèi)成員工作流

兩種工作流，相差的并不多，推薦先學(xué)習(xí) 工作流1。

3.1 Git 工作流1（非項(xiàng)目?jī)?nèi)成員）

因?yàn)椴皇琼?xiàng)目中的成員，無法直接修改項(xiàng)目中的代碼。所以需要先拷貝（Fork）項(xiàng)目到自己的遠(yuǎn)程倉庫中（GitHub賬號(hào)下），然后基于自己克隆過來的項(xiàng)目開發(fā)新的功能，最后提交 PR。

project_url：想要貢獻(xiàn)代碼的項(xiàng)目地址（源地址）
fork_project_url：克隆到自己遠(yuǎn)程倉庫的項(xiàng)目地址

Fork 項(xiàng)目
```
項(xiàng)目首頁 "Fork"
```
下載項(xiàng)目
```
git clone fork_project_url
```

增加源項(xiàng)目倉庫地址

git remote add <origin-name> project_url

切換到 develop 分支
```
git checkout develop
```
創(chuàng)建新的 feature或bug-fix 分支
```
git checkout -b <branchname>
```
保存你的修改（開發(fā)、修復(fù)bug）
```
git addgit commit -a
```
原因：
git commit -a 命令中的 -a 參數(shù)是開啟編輯器編輯 commit 信息，會(huì)在后面有詳細(xì)的說明。

更新到與遠(yuǎn)程倉庫同步

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

把最新的 develop 分支通過 rebase 命令合并到 feature 分支和對(duì)應(yīng)的遠(yuǎn)程分支
```
git checkout <branchname>git rebase -i --autosquash develop
```
原因：
你可以通過 --autosquash 命令把多個(gè) commit 壓縮成一個(gè) commit，這樣是的歷史更加整潔，一個(gè)功能就一個(gè)commit。通過 rebase 在本地就把沖突解決好，以避免提交 PR 時(shí)才發(fā)現(xiàn)沖突，導(dǎo)致提交失敗。
如果在合并時(shí)沒有出現(xiàn)沖突（conflict）就跳過這步；如果有沖突，可以先修改文件中的沖突，然后執(zhí)行下面的命令。
```
git add <file1> <file2> ...git rebase --continue
```
Rebase 命令會(huì)修改歷史，所以你 push 時(shí)可能會(huì)需要加上 -f 強(qiáng)制修改歷史。如果有其他人也在你的分支上開發(fā)，就使用 --force-with-lease 減少破壞
```
git push -f
```
原因：
因?yàn)橹皇切薷?feature 分支的歷史，而且每個(gè) feature 是獨(dú)立（理論上只有一個(gè)人開發(fā)），所以在 push 時(shí)加上 -f 參數(shù)并不會(huì)影響其他人的工作。
提交 Pull Request
Pull request 被接受、合并完成，就關(guān)閉該評(píng)論
如上述步驟都已完成，刪除你本地和遠(yuǎn)程的 feature 分支
sh git branch -d <branchname> git push origin --delete <remote-branchname>

3.2 Git 工作流2（項(xiàng)目?jī)?nèi)成員）

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

下載項(xiàng)目
```
git clone project_url
```
切換到 develop 分支
```
git checkout develop
```
創(chuàng)建新的 feature或bug-fix 分支
```
git checkout -b <branchname>
```
保存你的修改（開發(fā)、修復(fù)bug）
```
git addgit commit -a
```
原因：
git commit -a 命令中的 -a 參數(shù)是開啟編輯器（vim基本操作）編輯 commit 信息，會(huì)在后面有詳細(xì)的說明。

更新到與遠(yuǎn)程倉庫同步

git checkout developgit pull --rebase

把最新的 develop 分支通過 rebase 命令合并到 feature 分支和對(duì)應(yīng)的遠(yuǎn)程分支
```
git checkout <branchname>git rebase -i --autosquash develop
```
原因：
你可以通過 --autosquash 命令把多個(gè) commit 壓縮成一個(gè) commit，這樣是的歷史更加整潔，一個(gè)功能就一個(gè)commit。通過 rebase 在本地就把沖突解決好，以避免提交 PR 時(shí)才發(fā)現(xiàn)沖突，導(dǎo)致提交失敗。
如果在合并時(shí)沒有出現(xiàn)沖突（conflict）就跳過這步；如果有沖突，可以修改文件中的沖突，然后執(zhí)行下面的命令。
```
git add <file1> <file2> ...git rebase --continue
```
Rebase 命令會(huì)修改歷史，所以你 push 時(shí)可能會(huì)需要加上 -f 強(qiáng)制修改歷史。如果有其他人也在你的分支上開發(fā)，就使用 --force-with-lease 減少破壞
```
git push -f
```
原因：
因?yàn)橹皇切薷?feature 分支的歷史，而且每個(gè) feature 是獨(dú)立（理論上只有一個(gè)人開發(fā)），所以在 push 時(shí)加上 -f 參數(shù)并不會(huì)影響其他人的工作。
提交 Pull Request
Pull request 被接受、合并完成，就關(guān)閉該評(píng)論

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

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

3.3 編寫優(yōu)秀的 commit 信息

制定良好的創(chuàng)建 commit 規(guī)范，并堅(jiān)持使用，使得與他人合作更容易。下面是一些經(jīng)驗(yàn)和建議：

把 commit 信息分為標(biāo)題和內(nèi)容兩個(gè)部分，兩者之間要有個(gè)空行
原因：
Git 可將你的提交消息的第一行做為摘要
標(biāo)題控制在 50 個(gè)字符以內(nèi)，內(nèi)容最多不超過 72 個(gè)字符
原因：
commit 信息盡可能簡(jiǎn)潔和精準(zhǔn)
標(biāo)題首字母大寫
標(biāo)題不要有句號(hào)
標(biāo)題使用“祈求語句”
內(nèi)容中解釋為什么要有這次提交、如何解決問題、可能影響的地方
原因：
如果有需求、issues地址、可以附上。更多詳情

3.4 實(shí)踐

本節(jié)就一個(gè)實(shí)踐內(nèi)容，但是并不是很簡(jiǎn)單，請(qǐng)仔細(xì)閱讀并遵守：

向我的 test_project 項(xiàng)目的 develop 分支提交一個(gè)PR，要求如下：

在 README.md 文件中新啟一行，增加內(nèi)容為上一個(gè) commit 的 id 號(hào)
Commit 信息要按照上述 3.3 節(jié)要求書寫

提示： 可能會(huì)因?yàn)榻邮芴峤豁樞蚨a(chǎn)生沖突，如遇到?jīng)_突，要解決完沖突后重新提交。如遇問題，可參考 “4. 更多 Git 使用技巧”。

4. 更多 Git 使用技巧

俗話說：師傅領(lǐng)進(jìn)門修行靠個(gè)人。

用好一個(gè)工具或技能最好的方式就是不斷的使用，使用中必然會(huì)出現(xiàn)問題。當(dāng)你解決了足夠多的問題，你也就成為老司機(jī)了。

遇到問題：

請(qǐng)先閱讀錯(cuò)誤提示
通過搜索引擎尋找答案（國內(nèi)推薦使用 bing 搜索技術(shù)問題）
用自己的語言經(jīng)可能詳細(xì)的描述問題，并收集充足的信息后，在詢問老司機(jī)

最后，請(qǐng)拿走這本秘籍：git-tips，??

5. 建議收集

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

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

作者：削微寒

出處：http://www.cnblogs.com/xueweihan/

本博客的文章如無特殊說明，均為原創(chuàng)，轉(zhuǎn)載請(qǐng)注明出處。如未經(jīng)作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責(zé)任的權(quán)利。

http://www.cnblogs.com/xueweihan/p/7229456.html

分類導(dǎo)航