GitHub入門（2）

【學習自AndroidDeveloper】

Git 進階知識

1. 用戶名和郵箱

我們知道我們進行的每一次commit都會產生一條log，這條log標記了提交人的姓名與郵箱，以便其他人方便的查看與聯繫提交人，所以我們在進行提交代碼的第一步就是要設置自己的用戶名與郵箱。執行以下代碼：

git config --global user.name "stormzhang"
git config --global user.email "[email protected]"

以上進行了全局配置，當然有些時候我們的某一個項目想要用特定的郵箱，這個時候只需切換到你的項目，以上代碼把 –global 參數去除，再重新執行一遍就ok了。

PS：我們在 GitHub 的每次提交理論上都會在 主頁的下面產生一條綠色小方塊的記錄，如果你確認你提交了，但是沒有綠色方塊顯示，那肯定是你提交代碼配置的郵箱跟你 GitHub 上的郵箱不一致，GitHub 上的郵箱可以到 Setting -> Emails裏查看。

2. alias

我們知道我們執行的一些Git命令其實操作很頻繁的類似有：

git commit
git checkout
git branch
git status
...

這些操作非常頻繁，每次都要輸入完全是不是有點麻煩，有沒有一種簡單的縮寫輸入呢？比如我對應的直接輸入以下：

git c
git co
git br
git s
...

是不是很簡單快捷啊？這個時候就用到了alias配置了，翻譯過來就是別名的意思，輸入以下命令就可以直接滿足了以上的需求。

git config --global alias.co checkout  # 別名
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch

當然以上別名不是固定的，你完全可以根據自己的習慣去定製，除此之外還可以設置組合，比如：

git config --global alias.psm 'push origin master'
git config --global alias.plm 'pull origin master'

之後經常用到的git push origin master 和 git pull origin master 直接就用 git psm 和 git plm 代替了，是不是很方便？

另外這裏給大家推薦一個很強大的 alias 命令，我們知道我們輸入 git log 查看日誌的時候是類似這樣的：

告訴大家一個比較屌的命令，輸入git log –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit –date=relative 然後日誌這樣了：

是不是比較清晰，整個分支的走向也很明確，但是每次都要輸這麼一大串是不是也很煩？這時候你就該想到 alias 啊：

git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"

這樣以後直接輸入 git lg 就行了。

3. 其他配置

當然還有一些其他有用的配置，默認情況下 git 用的編輯器是 vi ，如果不喜歡可以改成其他編輯器，比如我習慣 vim 。

git config --global core.editor "vim"  # 設置Editor使用vim

你們如果喜歡其他編輯器可自行搜索配置，前提是本機有安裝。

有些人納悶我的終端怎麼有各種顏色，自己卻不是這樣的，那是因爲你們沒有開啓給 Git 着色，輸入如下命令即可：

git config --global color.ui true

還有些其他的配置如：

git config --global core.quotepath false # 設置顯示中文文件名

以上基本所有的配置就差不多了，默認這些配置都在 ~/.gitconfig 文件下的，你可以找到這個文件查看自己的配置，也可以輸入 git config -l 命令查看。

4. diff

diff命令算是很常用的，使用場景是我們經常在做代碼改動，但是有的時候2天前的代碼了，做了哪些改動都忘記了，在提交之前需要確認下，這個時候就可以用diff來查看你到底做了哪些改動，舉個例子，比如我有一個 a.md 的文件，我現在做了一些改動，然後輸入 git diff 就會看到如下：

紅色的部分前面有個 - 代表我刪除的，綠色的部分前面有個 + 代表我增加的，所以從這裏你們很一目瞭然的知道我到底對這個文件做了哪些改動。

值得一提的是直接輸入 git diff 只能比較當前文件和暫存區文件差異，什麼是暫存區？就是你還沒有執行 git add 的文件。

當然跟暫存區做比較之外，他還可以有其他用法，如比較兩次 commit 之間的差異，比較兩個分支之間的差異，比較暫存區和版本庫之間的差異等，具體用法如下：

git diff <$id1> <$id2>   # 比較兩次提交之間的差異
git diff <branch1>..<branch2> # 在兩個分支之間比較 
git diff --staged   # 比較暫存區和版本庫差異

5. checkout

我們知道 checkout 一般用作切換分支使用，比如切換到 develop 分支，可以執行：

git checkout develop

但是 checkout 不只用作切換分支，他可以用來切換tag，切換到某次commit，如：

git checkout v1.0
git checkout ffd9f2dd68f1eb21d36cee50dbdd504e95d9c8f7 # 後面的一長串是commit_id，是每次commit的SHA1值，可以根據 git log 看到。

除了有“切換”的意思，checkout 還有一個撤銷的作用，舉個例子，假設我們在一個分支開發一個小功能，剛寫完一半，這時候需求變了，而且是大變化，之前寫的代碼完全用不了了，好在你剛寫，甚至都沒有 git add 進暫存區，這個時候很簡單的一個操作就直接把原文件還原：

git checkout a.md

這裏稍微提下，checkout 命令只能撤銷還沒有 add 進暫存區的文件。

6. stash

設想一個場景，假設我們正在一個新的分支做新的功能，這個時候突然有一個緊急的bug需要修復，而且修復完之後需要立即發佈。當然你說我先把剛寫的一點代碼進行提交不就行了麼？這樣理論上當然是ok的，但是這會產品垃圾commit，原則上我們每次的commit都要有實際的意義，你的代碼只是剛寫了一半，還沒有什麼實際的意義是不建議就這樣commit的，那麼有沒有一種比較好的辦法，可以讓我暫時切到別的分支，修復完bug再切回來，而且代碼也能保留的呢？

這個時候 stash 命令就大有用處了，前提是我們的代碼沒有進行 commit ，哪怕你執行了 add 也沒關係，我們先執行

git stash

命令，什麼意思呢？意思就是把當前分支所有沒有 commit 的代碼先暫存起來，這個時候你再執行 git status 你會發現當前分支很乾淨，幾乎看不到任何改動，你的代碼改動也看不見了，但其實是暫存起來了。執行

git stash list

你會發現此時暫存區已經有了一條記錄。

這個時候你可以切換會其他分支，趕緊把bug修復好，然後發佈。之後一切都解決了，你再切換回來繼續做你之前沒做完的功能，但是之前的代碼怎麼還原呢？

git stash apply

你會發現你之前的代碼全部又回來了，就好像一切都沒發生過一樣，緊接着你最好需要把暫存區的這次 stash 記錄刪除，執行：

git stash drop

就把最近一條的 stash 記錄刪除了，是不是很方便？其實還有更方便的，你可以使用：

git stash pop

來代替 apply 命令，pop 跟 apply 的唯一區別就是 pop 不但會幫你把代碼還原，還自動幫你把這條 stash 記錄刪除，省的自己再 drop 一次了，爲了驗證你可以緊接着執行 git stash list 命令來確認是不是已經沒有記錄了。

最後還有一個命令介紹下：

git stash clear

就是清空所有暫存區的記錄，drop 是隻刪除一條，當然後面可以跟 stash_id 參數來刪除指定的某條記錄，不跟參數就是刪除最近的，而 clear 是清空。

7. merge & rebase

我們知道 merge 分支是合併的意思，我們在一個 featureA 分支開發完了一個功能，這個時候需要合併到主分支 master 上去，我們只需要進行如下操作：

git checkout master
git merge featureA

其實 rebase 命令也是合併的意思，上面的需求我們一樣可以如下操作：

git checkout master
git rebase featureA

rebase 跟 merge 的區別你們可以理解成有兩個書架，你需要把兩個書架的書整理到一起去，第一種做法是 merge ，比較粗魯暴力，就直接騰出一塊地方把另一個書架的書全部放進去，雖然暴力，但是這種做法你可以知道哪些書是來自另一個書架的；第二種做法就是 rebase ，他會把兩個書架的書先進行比較，按照購書的時間來給他重新排序，然後重新放置好，這樣做的好處就是合併之後的書架看起來很有邏輯，但是你很難清晰的知道哪些書來自哪個書架的。

只能說各有好處的，不同的團隊根據不同的需要以及不同的習慣來選擇就好。

8. 解決衝突

假設這樣一個場景，A和B兩位同學各自開了兩個分支來開發不同的功能，大部分情況下都會盡量互不干擾的，但是有一個需求A需要改動一個基礎庫中的一個類的方法，不巧B這個時候由於業務需要也改動了基礎庫的這個方法，因爲這種情況比較特殊，A和B都認爲不會對地方造成影響，等兩人各自把功能做完了，需要合併的到主分支 master 的時候，我們假設先合併A的分支，這個時候沒問題的，之後再繼續合併B的分支，這個時候想想也知道就有衝突了，因爲A和B兩個人同時更改了同一個地方，Git 本身他沒法判斷你們兩個誰更改的對，但是這個時候他會智能的提示有 conflicts ，需要手動解決這個衝突之後再重新進行一次 commit 提交。我隨便在項目搞了一個衝突做下示例：

以上截圖裏就是衝突的示例，衝突的地方由 ==== 分出了上下兩個部分，上部分一個叫 HEAD 的字樣代表是我當前所在分支的代碼，下半部分是一個叫 baidu_activity 分支的代碼，可以看到 HEAD 對 gradle 插件進行了升級，同時新增了一個插件，所以我們很容易判斷哪些代碼該保留，哪些代碼該刪除，我們只需要移除掉那些老舊代碼，而且同時也要把那些 <<< HEAD、==== 以及 >>>>>>baidu_activity 這些標記符號也一併刪除，最後進行一次 commit 就ok了。

我們在開發的過程中一般都會約定儘量大家寫的代碼不要彼此影響，以減少出現衝突的可能，但是衝突總歸無法避免的，我們需要了解並掌握解決衝突的方法。

團隊合作利器 Branch

Git 相比於 SVN 最強大的一個地方就在於「分支」，Git 的分支操作簡直不要太方便，而實際項目開發中團隊合作最依賴的莫過於分支了，關於分支前面的系列也提到過，但是本篇會詳細講述什麼是分支、分支的具體操作以及實際項目開發中到底是怎麼依賴分支來進行團隊合作的。

1. 什麼是分支？

我知道讀者中肯定有些人對分支這個概念比較模糊，其實你們可以這麼理解，你們幾個人一起去旅行，中間走到一個三岔口，每條路可能有不同的風景，你們約定 3 天之後在某地匯聚，然後各自出發了。而這三條分叉路就可以理解成你們各自的分支，而等你們匯聚的時候相當於把你們的分支進行了合併。

2. 分支的常用操作

通常我們默認都會有一個主分支叫 master ，下面我們先來看下關於分支的一些基本操作：

新建一個叫 develop 的分支

git branch develop

這裏稍微提醒下大家，新建分支的命令是基於當前所在分支的基礎上進行的，即以上是基於 mater 分支新建了一個叫做 develop 的分支，此時 develop 分支跟 master 分支的內容完全一樣。如果你有 A、B、C三個分支，三個分支是三位同學的，各分支內容不一樣，如果你當前是在 B 分支，如果執行新建分支命令，則新建的分支內容跟 B 分支是一樣的，同理如果當前所在是 C 分支，那就是基於 C 分支基礎上新建的分支。

切換到 develop 分支

git checkout develop

如果把以上兩步合併，即新建並且自動切換到 develop 分支：

git checkout -b develop

把 develop 分支推送到遠程倉庫

git push origin develop

如果你遠程的分支想取名叫 develop2 ，那執行以下代碼：

git push origin develop:develop2

但是強烈不建議這樣，這會導致很混亂，很難管理，所以建議本地分支跟遠程分支名要保持一致。

查看本地分支列表

git branch

查看遠程分支列表

git branch -r

刪除本地分支

git branch -d develop

git branch -D develop (強制刪除)

刪除遠程分支

git push origin :develop

如果遠程分支有個 develop ，而本地沒有，你想把遠程的 develop 分支遷到本地：

git checkout develop origin/develop

同樣的把遠程分支遷到本地順便切換到該分支：

git checkout -b develop origin/develop

3. 基本的團隊協作流程

一般來說，如果你是一個人開發，可能只需要 master、develop 兩個分支就 ok 了，平時開發在 develop 分支進行，開發完成之後，發佈之前合併到 master 分支，這個流程沒啥大問題。

如果你是 3、5 個人，那就不一樣了，有人說也沒多大問題啊，直接可以新建 A、B、C 三個人的分支啊，每人各自開發各自的分支，然後開發完成之後再逐步合併到 master 分支。然而現實卻是，你正在某個分支開發某個功能呢，這時候突然發現線上有一個很嚴重的 bug ，不得不停下手頭的工作優先處理 bug ，而且很多時候多人協作下如果沒有一個規範，很容易產生問題，所以多人協作下的分支管理規範很重要，就跟代碼規範一樣重要，以下就跟大家推薦一種我們內部在使用的一種分支管理流程 Git Flow。

4. Git Flow

準確的說 Git Flow 是一種比較成熟的分支管理流程，我們先看一張圖能清晰的描述他整個的工作流程：

第一次看上面那個圖是不是一臉懵逼？跟我當時一樣，不急，我來用簡單的話給你們解釋下。

一般開發來說，大部分情況下都會擁有兩個分支 master 和 develop，他們的職責分別是：

master：永遠處在即將發佈(production-ready)狀態

develop：最新的開發狀態

確切的說 master、develop 分支大部分情況下都會保持一致，只有在上線前的測試階段 develop 比 master 的代碼要多，一旦測試沒問題，準備發佈了，這時候會將 develop 合併到 master 上。

但是我們發佈之後又會進行下一版本的功能開發，開發中間可能又會遇到需要緊急修復 bug ，一個功能開發完成之後突然需求變動了等情況，所以 Git Flow 除了以上 master 和 develop 兩個主要分支以外，還提出了以下三個輔助分支：

feature: 開發新功能的分支, 基於 develop, 完成後 merge 回 develop

release: 準備要發佈版本的分支, 用來修復 bug，基於 develop，完成後 merge 回 develop 和 master

hotfix: 修復 master 上的問題, 等不及 release 版本就必須馬上上線. 基於 master, 完成後 merge 回 master 和 develop

什麼意思呢？

舉個例子，假設我們已經有 master 和 develop 兩個分支了，這個時候我們準備做一個功能 A，第一步我們要做的，就是基於 develop 分支新建個分支：

git branch feature/A

看到了吧，其實就是一個規範，規定了所有開發的功能分支都以 feature 爲前綴。

但是這個時候做着做着發現線上有一個緊急的 bug 需要修復，那趕緊停下手頭的工作，立刻切換到 master 分支，然後再此基礎上新建一個分支：

git branch hotfix/B

代表新建了一個緊急修復分支，修復完成之後直接合併到 develop 和 master ，然後發佈。

然後再切回我們的 feature/A 分支繼續着我們的開發，如果開發完了，那麼合併回 develop 分支，然後在 develop 分支屬於測試環境，跟後端對接並且測試的差不多了，感覺可以發佈到正式環境了，這個時候再新建一個 release 分支：

git branch release/1.0

這個時候所有的 api、數據等都是正式環境，然後在這個分支上進行最後的測試，發現 bug 直接進行修改，直到測試 ok 達到了發佈的標準，最後把該分支合併到 develop 和 master 然後進行發佈。

以上就是 Git Flow 的概念與大概流程，看起來很複雜，但是對於人數比較多的團隊協作現實開發中確實會遇到這麼複雜的情況，是目前很流行的一套分支管理流程，但是有人會問每次都要各種操作，合併來合併去，有點麻煩，哈哈，這點 Git Flow 早就想到了，爲此還專門推出了一個 Git Flow 的工具，並且是開源的：

GitHub 開源地址：https://github.com/nvie/gitflow

簡單點來說，就是這個工具幫我們省下了很多步驟，比如我們當前處於 master 分支，如果想要開發一個新的功能，第一步切換到 develop 分支，第二步新建一個以 feature 開頭的分支名，有了 Git Flow 直接如下操作完成了：

git flow feature start A

這個分支完成之後，需要合併到 develop 分支，然而直接進行如下操作就行：

git flow feature finish A

如果是 hotfix 或者 release 分支甚至會自動幫你合併到 develop、master 兩個分支。

GitHub 常見的幾種操作

我們都說開源社區最大的魅力是人人多可以參與進去，發揮衆人的力量，讓一個項目更完善，更強壯。那麼肯定有人疑問，我自己目前還沒有能力開源一個項目，但是想一起參與到別的開源項目中，該怎麼操作呢？那麼今天，就來給大家一起介紹下 GitHub 上的一些常見的操作，看完之後你就知道方法了。

我們姑且以 Square 公司開源的 Retrofit 爲例來介紹。

打開鏈接：https://github.com/square/retrofit

然後看到如下的項目主頁：

可以看到一個項目可以進行的操作主要就是兩部分，第一部分包括 Watch、Star、Fork ，這三個操作之前的系列介紹過了，這裏就不囉嗦了。

我們着重來介紹第二部分，分別包括 Code、Issues、Pull requests、Projects、Wiki、Pulse、Graphs。接下來我們來一個個解釋下。

• Code

這個好理解，就是你項目的代碼文件而已，這裏說明一下，每個項目通常都會有對該項目的介紹，只需要在項目的根目錄裏添加一個 README.md 文件就可以，使用 markdown 語法，GitHub 自動會對該文件進行渲染。

• Issues

Issues 代表該項目的一些問題或者 bug，並不是說 Issues 越少越好，Issues 被解決的越多說明項目作者或者組織響應很積極，也說明該開源項目的作者很重視該項目。我們來看下 Retrofit 的 Issues 主頁，截至目前 close（解決） 了 1305 個 Issue，open （待解決）狀態的有 37 個，這解決問題的比例與速度值得每位開源項目的作者學習。

同樣的，大家在使用一些開源項目有問題的時候都可以提 Issue，可以通過點擊右上角的 New Issue 來新建 Issue，需要添加一個標題與描述就可以了，這個操作很簡單。

• Pull requests

我們都知道 GitHub 的最大魅力在於人人都可參與，比如別人開源一個項目，我們每個人都可以一起參與開發，一起來完善，而這都通過 Pull requests 來完成，簡稱 PR。這個沒法在 Retrofit 演示，下面我就以我自己在 GitHub 上的一個項目 9GAG 來給大家詳細演示下怎麼給一個項目發起 PR：

提前說明下，你必須確保你可以正常向 GitHub 提交代碼，如果不可以的話，請看我之前的系列文章。

第一步登錄你的 GitHub 賬號，然後找到你想發起 PR 的項目，這裏以 9GAG 爲例，點擊右上角的 Fork 按鈕，然後該項目就出現在了你自己賬號的 Repository 裏。

請注意，這個項目原本是屬於 GitHub 賬號 stormzhang 下的，爲了演示，我自己又重新註冊了另一個賬號叫 googdev 單純爲了演示而用。

Fork 之後，在賬號 googdev 下多了一個 9GAG 的項目，截圖顯示如下：

可以看到 Fork 過來的項目標題底部會顯示一行小字：fork from stormzhang/9GAG ，除此之外，項目代碼跟原項目一模一樣，對於原項目來說，相當於別人新建了一個分支而已。

第二步，把該項目 clone 到本地，然後修改的 bug 也好，想要新增的功能也好，總之把自己做的代碼改動開發完，保存好。爲了方便演示，我這裏只在原項目的 README.md 文件添加了一行文字：Fork from stormzhang !

接着，把自己做的代碼改動 push 到 你自己的 GitHub 上去。

相信看過我前面教程的同學這一步應該都會，不會的可以滾回去看前面的教程了。

第三步，點擊你 Fork 過來的項目主頁的 Pull requests 頁面，

點擊 New pull request 按鈕緊接着到如下頁面：

這個頁面自動會比較該項目與原有項目的不同之處，最頂部聲明瞭是 stormzhang/9GAG 項目的 master 分支與你 fork 過來的 googdev/9GAG 項目 master 分支所做的比較。

然後最頂部可以方便直觀的看到到底代碼中做了哪些改動，你們也看到我就是加了一句 Fork from stormzhang !

同樣的我寫好標題和描述，然後我們點擊中間的 Create pull request 按鈕，至此我們就成功給該項目提交了一個 PR。

然後就等着項目原作者 review 你的代碼，並且決定會不會接受你的 PR，如果接受，那麼恭喜你，你已經是該項目的貢獻者之一了。

• Projects

這個是最新 GitHub 改版新增的一個項目，這個項目就是方便你把一些 Issues、Pull requests 進行分類，反正我覺得該功能很雞肋，起碼到目前爲止基本沒人用該功能，你們瞭解下就好。

• Wiki

一般來說，我們項目的主頁有 README.me 基本就夠了，但是有些時候我們項目的一些用法很複雜，需要有詳細的使用說明文檔給開源項目的使用者，這個時候就用到了 Wiki。

使用起來也很簡單，直接 New Page ，然後使用 markdown 語法即可進行編寫。

• Pulse

Pulse 可以理解成該項目的活躍彙總。包括近期該倉庫創建了多少個 Pull Request 或 Issue，有多少人蔘與了這個倉庫的開發等，都可以在這裏一目瞭然。

根據這個頁面，用戶可以判斷該項目受關注程度以及項目作者是否還在積極參與解決這些問題等。

• Graphs

Graphs 是以圖表的形式來展示該項目的一個整體情況。比如項目的全部貢獻人，比如 commits 的圍度分析，比如某天代碼提交的頻繁程度等。

• Settings

如果一個項目是自己的，那麼你會發現會多一個菜單 Settings，這裏包括了你對整個項目的設置信息，比如對項目重命名，比如刪除該項目，比如關閉項目的 Wiki 和 Issues 功能等，不過大部分情況下我們都不需要對這些設置做更改。感興趣的，可以自行看下這裏的設置有哪些功能。

以上就包含了一個 GitHub 項目的所有操作，相信大家看完之後對 GitHub 上一些常用的操作都熟悉了，從現在開始，請一起參與到開源社區中來吧，開源社區需要我們每個人都貢獻一份力，這樣開源社區才能越來越強大，也才能對更多的人有幫助！

如何發現優秀的開源項目

GitHub 其中一個最重要的作用就是發現全世界最優秀的開源項目，你沒事的時候刷刷微博、知乎，人家沒事的時候刷刷 GitHub ，看看最近有哪些流行的項目，久而久之，這差距就越來越大，那麼如何發現優秀的開源項目呢？這篇文章我就來給大家介紹下。

1. 關注一些活躍的大牛
   GitHub 主頁有一個類似微博的時間線功能，所有你關注的人的動作，比如 star、fork 了某個項目都會出現在你的時間線上，這種方式適合我這種比較懶的人，不用主動去找項目，而這種基本是我每天獲取信息的一個很重要的方式。不知道怎麼關注這些人？那麼很簡單，關注我 stormzhang ，以及我 GitHub 上關注的一些大牛，基本就差不多了。

1. Trending

點擊下圖的 Explore 菜單到“發現”頁面

緊接着點擊 Trending 按鈕

這個 Trending 頁面是幹嘛的呢？直譯過來就是趨勢的意思，就是說這個頁面你可以看到最近一些熱門的開源項目，這個頁面可以算是很多人主動獲取一些開源項目最好的途徑，可以選擇「當天熱門」、「一週之內熱門」和「一月之內熱門」來查看，並且還可以分語言類來查看，比如你想查看最近熱門的 Android 項目，那麼右邊就可以選擇 Java 語言。

這樣頁面推薦大家每隔幾天就去看下，主動發掘一些優秀的開源項目。

1. Search

除了 Trending ，還有一種最主動的獲取開源項目的方式，那就是 GitHub 的 Search 功能。

舉個例子，你是做 Android 的，接觸 GitHub 沒多久，那麼第一件事就應該輸入 android 關鍵字進行搜索，然後右上角選擇按照 star 來排序，結果如下圖：

如果你是學習 iOS 的，那麼不妨同樣的方法輸入 iOS 關鍵字看看結果：

可以看到按照 star 數，排名靠前基本是一些比較火的項目，一定是很有用，纔會這麼火。值得一提的是左側依然可以選擇語言進行過濾。

而對於實際項目中用到一些庫，基本上都會第一時間去 GitHub 搜索下有沒有類似的庫，比如項目中想採用一個網絡庫，那麼不妨輸入 android http 關鍵字進行搜索，因爲我只想找到關於 Android 的項目，所以搜索的時候都會加上 android 關鍵字，按照 star 數進行排序，我們來看下結果：

可以看到 Retrofit、OkHttp、android-async-http 是最流行的網絡庫，只不過 android-async-http 的作者不維護了，之前很多人問我網絡庫用哪個比較好？哪怕你對每個網絡庫都不是很瞭解，那麼單純的按照這種方式你都該優先選擇 Retrofit 或者 OkHttp，而目前絕大部分 Android 開發者確實也都是在用這兩個網絡庫，當然還有部分在用 Volley 的，因爲 google 沒有選擇在 GitHub 開源 volley，所以搜不到 volley 的上榜。

除此之外，GitHub 的 Search 還有一些小技巧，比如你想搜索的結果中 star 數大於1000的，那麼可以這樣搜索：

android http stars:>1000

當然還有其他小技巧，但是我覺得不是很重要，就不多說了。

有些人如果習慣用 Google 進行搜索，那麼想搜索 GitHub 上的結果，不妨前面加 GitHub 關鍵字就ok了，比如我在 google 裏輸入 GitHub android http ，每個關鍵字用空格隔開，然後搜索結果如下：

可以看到，基本也是我們想要的結果，只不過排序就不是單純的按照 star 來排序了。

福利大放送

相信以上三種方法夠大家遨遊在 GitHub 的海洋了，最後給大家獻上一些福利，這些項目是 GitHub 上影響力很大，同時又對你們很有用的項目：

• free-programming-books

這個項目目前 star 數排名 GitHub 第三，總 star 數超過6w，這個項目整理了所有跟編程相關的免費書籍，而且全球多國語言版的都有，中文版的在這裏：free-programming-books-zh，有了這個項目，理論上你可以獲取任何編程相關的學習資料，強烈推薦給你們！

• oh-my-zsh

俗話說，不會用 shell 的程序員不是真正的程序員，所以建議每個程序員都懂點 shell，有用不說，裝逼利器啊！而 oh-my-zsh 毫無疑問就是目前最流行，最酷炫的 shell，不多說了，懂得自然懂，不懂的以後你們會懂的！

• awesome

GitHub 上有各種 awesome 系列，簡單來說就是這個系列蒐羅整理了 GitHub 上各領域的資源大彙總，比如有 awesome-android, awesome-ios, awesome-java, awesome-python 等等等，就不截圖了，你們自行去感受。

• github-cheat-sheet

GitHub 的使用有各種技巧，只不過基本的就夠我們用了，但是如果你對 GitHub 超級感興趣，想更多的瞭解 GitHub 的使用技巧，那麼這個項目就剛好是你需要的，每個 GitHub 粉都應該知道這個項目。

• android-open-project

這個項目是我一個好朋友 Trinea 整理的一個開源項目，基本囊括了所有 GitHub 上的 Android 優秀開源項目，但是缺點就是太多了不適合快速搜索定位，但是身爲 Android 開發無論如何你們應該知道這個項目。

• awesome-android-ui

這個項目跟上面的區別是，這個項目只整理了所有跟 Android UI 相關的優秀開源項目，基本你在實際開發終於到的各種效果上面都幾乎能找到類似的項目，簡直是開發必備。

• Android_Data

這個項目是我的邪教羣的一位管理員整理的，幾乎包括了國內各種學習 Android 的資料，簡直太全了，我爲這個項目也稍微做了點力，強烈推薦你們收藏起來。

• AndroidInterview-Q-A

這個就不多說了，之前給大家推薦過的，國內一線互聯網公司內部面試題庫。

• LearningNotes

這是一份非常詳細的面試資料，涉及 Android、Java、設計模式、算法等等等，你能想到的，你不能想到的基本都包含了，可以說是適應於任何準備面試的 Android 開發者，看完這個之後別說你還不知道怎麼面試！