版本控制工具 Git

1. 版本控制工具

使用文件或文件夾進行版本管理，有缺點：

多個文件，保留全部版本時，須要將多個文件保存在本地
協同操做，多人協同操做時，須要將文件發來發去...
容易丟失，被刪除意味着永遠失去（能夠選擇網盤）
爲了解決上述問題，應運而生了版本管理工具：

VSS-- Visual Source Safe
此工具是Microsoft提供的，是使用的至關廣泛的工具之一，他能夠與VS.net進行無縫集成，成爲了獨立開發人員和小型開發團隊所適合的工具，基本上Window平臺上開發的中小型企業，當規模較大後，其性能一般是沒法忍受的，對分支與並行開發支持的比較有限。
CVS--Concurrent Versions System
此工具是一個開源工具，與後面提到的SVN是同一個廠家：Collab.Net提供的。CVS是源於unix的版本控制工具，對於CVS的安裝和使用最好對unix的系統有所瞭解能更容易學習，CVS的服務器管理須要進行各類命令行操做。目前，CVS的客戶端有winCVS的圖形化界面，服務器端也有CVSNT的版本，易用性正在提升。
SVN --CollabNet Subversion
此工具是在CVS 的基礎上，由CollabNet提供開發的，也是開源工具,應用比較普遍。他修正cvs的一些侷限性，適用範圍同cvs，目前有一些基於SVN的第三方工具，如TortoiseSVN,是其客戶端程序，使用的也至關普遍。在權限管理，分支合併等方面作的很出色，他能夠與Apache集成在一塊兒進行用戶認證。不過在權限管理方面目前尚未個很好用的界面化工具，SVNManger對於已經使用SVN進行配置的項目來講，基本上是沒法應用的，但對於從頭開始的項目是能夠的，功能比較強大，可是搭建svnManger比較麻煩。是一個跨平臺的軟件，支持大多數常見的操做系統。做爲一個開源的版本控制系統,Subversion 管理着隨時間改變的數據。 這些數據放置在一箇中央資料檔案庫中。 這個檔案庫很像一個普通的文件服務器, 不過它會記住每一次文件的變更。 這樣你就能夠把檔案恢復到舊的版本, 或是瀏覽文件的變更歷史。Subversion 是一個通用的系統, 可用來管理任何類型的文件, 其中包括了程序源碼。
BitKeeper
是由BitMover公司提供的，BitKeeper自稱是「分佈式」可擴縮SCM系統。不是採用C/S結構，而是採用P2P結構來實現的，一樣支持變動任務，全部變動集的操做都是原子的，與svn,cvs一致。
GIT
Git是一個開源的分佈式版本控制系統，用以有效、高速的處理從很小到很是大的項目版本管理.Git 是 Linus Torvalds 爲了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。Torvalds 開始着手開發 Git 是爲了做爲一種過渡方案來替代 BitKeeper，後者以前一直是 Linux 內核開發人員在全球使用的主要源代碼工具。開放源碼社區中的有些人以爲 BitKeeper 的許可證並不適合開放源碼社區的工做，所以 Torvalds 決定着手研究許可證更爲靈活的版本控制系統。儘管最初 Git 的開發是爲了輔助 Linux 內核開發的過程，可是咱們已經發如今不少其餘自由軟件項目中也使用了 Git。例如 最近就遷移到 Git 上來了，不少 Freedesktop 的項目也遷移到了 Git 上。
版本管理工具都通常包含客戶端和服務端：

客戶端（用戶）：本地編寫內容，向服務端獲取或提交內容
服務端（網盤）：保存全部版本的文件

View Code

Git使用

 1 git init 初始化
 2 生成.git
 3 
 4 ---------工做區--------------- ---------------緩存區-----------版本庫(.git)
 5                                  git.add                           git.commit
 6 本來的文件|被修改的文件
 7 git會自動檢測哪些文件被修改了
 8 
 9 git status  查看狀態
10 
11 git add 文件名
12 git commit -m '提交信息'
13 
14 git ls-tree head   查看版本庫中的文件
15 git ls-files -s      查看版本和緩存區全部的文件
16 
17 commit以前要配置用戶信息：
18 git config --local user.name ''
19 git config --local user.email ''

第一階段

 1          回滾：
 2                git reset --hard 版本號
 3                git log
 4 
 5          回滾到回滾以前的狀態：
 6                 git reflog
 7 
 8                 git reset --max   a615783
 9 
10        修改bug的方式:
11        方式一：
12                出現了一個bug:   出現bug的文件與正在作修改的文件不一樣
13           git stash         將當前已經作過的修改，保存到一個臨時的地方
14           修復線上的bug
15           git stash list    查看臨時的地方保存的修改
16           git stash pop  將臨時的地方放置的修改內容從新放回到工做區
17 
18       又出現了一個bug:   出現bug的文件與正在作修改的文件相同
19            git stash
20            修復bug
21            git stash pop 出現衝突，手動解決
22                   列:
23 <<<<<<< Updated upstream
24 同城交友網站
25 張小戈
26 =======
27 同城交友網站
28 張小戈
29 開發直播功能到一半
30 >>>>>>> Stashed changes
31 
32        其餘：
33                  git stash apply
34                  git stash drop
35 
36        方式二：
37                    分支   master ：只保留線上版本
38                              dev：開發版本
39                              bug:改bug版本
40 
41                    git branch dev    建立分支     注意當前所在分支,根據當前分支複製一份
42                    git  checkout dev    進入分支
43 
44                     出現bug:
45                           git checkout master
46                           git branch bug
47                           git checkout bug
48                           修復bug
49                     合併：
50                            git checkout master
51                            git merge bug
52                      刪除bug分支：
53                            git branch -d bug
54                      繼續開發：
55                             git checkout dev
56                             ..........
57                      合併：
58                            git checkout master
59                            git merge dev
60                            無衝突：過
61                            有衝突: 手動修改............

第二階段

 1 公司：
 2 git remote add origin https://github.com/a877252372/wwwww.git   創建遠程鏈接別名
 3 
 4 git checkout master
 5 git push origin master # 推送 到遠程倉庫
 6 git push origin dev
 7 下班回家
 8 回家：
 9 git clone https://github.com/a877252372/wwwww.git    克隆到本身的電腦上
10 
11 cd wwwww
12 
13 git branch dev origin/dev  根據遠程倉庫的dev創建開發分支
14 git checkout dev
15 
16 寫代碼
17 
18 git add .
19 git commit ...
20 git push origin dev    # 推送 到遠程倉庫
21 
22 公司：
23 git checkout dev
24 git fetch origin dev
25 git pull origin dev 勁大   首先更新代碼，避免衝突推送不成功
26 
27 功能11
28 git add .
29 git commit ...
30 git push origin dev
31 
32 功能12：（忘記提交，下班回家）
33 git add .
34 git commit ...
35 回家：
36 git branch dev
37 git pull origin dev
38 功能13：
39 git add .
40 git commit ...
41 git push origin dev
42 公司：
43 獲取代碼，
44 git pull origin dev   首先更新代碼，避免功能12與遠程倉庫中的功能13衝突推送不成功
45 
46 無衝突：過
47 有衝突：
48 手動解決
49 git add .
50 git commit -m '解決衝突'

第三階段：遠程倉庫

 

什麼是Git

經過前面的學習瞭解到GitHub 是基於 Git 的，因此也就意味着 Git 是基礎，若是不會使用 Git ，那麼接下來會徹底繼續不下去，所以，今天的課程就來講說 Git ，本課程先介紹一些最基本的、最經常使用的一些 Git 知識，爭取讓你迅速掌握 Git 。

1. 什麼是 Git？

Git 是 Linux 發明者 Linus 開發的一款新時代的版本控制系統，那麼到底什麼是版本控制系統呢？網上各類詳細的介紹，大多枯燥乏味，對於新手很難理解，這裏只舉幾個例子來幫助你們理解。

熟悉編程的人都知道，在軟件開發中源代碼是最重要的，那麼對源代碼的管理也就變得更加劇要了，如下幾種狀況在開發中最爲常見：

• 在開發程序時，爲了防止代碼丟失，須要在本地機器與遠程服務器各存放一份，而且還須要有一套機制使本地能夠與遠程同步；
• 開發中一般是幾我的作同一個項目，要對同一份代碼作更改，這個時候既須要你們互不影響，又須要各自能夠同步別人的代碼；
• 開發的過程當中免不了有bug，有時候剛發佈的功能就出現了嚴重的bug，這個時候須要緊急對代碼進行還原；
• 隨着版本迭代的增多，做爲開發者須要清楚的知道每個歷史版本的代碼更改記錄，甚至知道每一個人歷史提交代碼的狀況。

以上的這些狀況，都是版本控制系統能夠解決的問題。版本控制實際上就是一種記錄一個或若干文件內容變化，以便未來查閱特定版本修訂狀況的系統，對於軟件開發領域來講版本控制是最重要的環節，而 Git 毫無疑問是當下最流行、最好用的版本控制系統。

2.Git 安裝

Git 是一個版本控制系統，也能夠理解爲一個工具，跟 Java 相似，使用以前必須先進行下載安裝， Mac 筆記本上其實系統自帶了 Git ，不過這裏統一提供各平臺的安裝方式，這部分就不過多介紹，相信你們能夠搞定。

• Mac：https://sourceforge.net/projects/git-osx-installer/
• Windows：https://git-for-windows.github.io/
• Linux：apt-get install git

3.如何學習 Git

安裝好 Git 以後，怎麼學習是個問題，其實關於 Git 有不少圖形化的軟件能夠操做，這裏推薦你們使用命令行開始學習，若是你沒接觸過命令行，開始可能會有所抵觸，可是大量實踐證實，只有一開始學習命令行，才能讓你對 Git 的每一步操做有深入的理解，而在熟練掌握以後，使用任何的圖形化的軟件均可以去操做。

Git命令列表

怎麼判斷 Git 有沒有安裝成功？在命令行裏輸入 git ，若是出現如下提示證實你已經安裝成功了。個人運行環境是在window上，若是是在mac上，道理是同樣的

Git 全部的操做命令開頭都要以 git 開頭，上面列舉了最經常使用的一些 Git 命令，後面有一句英文解釋這個命令的意義，都是比較簡單的詞彙，不妨試着翻譯一下，可是若是沒有實際操做仍然很差理解，下面就以一個實際的操做來介紹一些經常使用命令的含義。

Git經常使用命令舉例

第一步，須要新建一個文件夾，在文件夾裏新建一個文件（我是用 Linux 命令新建的，Windows用戶能夠本身手動新建）

• mkdir test （建立文件夾test）
• cd test （切換到test目錄）
• touch a.md （新建a.md文件）

注意：在進行任何 Git 操做以前，都要先切換到 Git 倉庫目錄，也就是要先切換到項目的文件夾目錄下。

能夠是用cmd下cd到目錄下，

也能夠是圖形操做到項目目錄下，右鍵git bash here

最終回打開另一個命令窗口：

這個時候隨便操做一個命令，好比 git status ，能夠看到以下提示（不要糾結顏色，配置與主題不同而已）：

意思是當前目錄還不是一個 Git 倉庫。

1.git init

這個時候就要用到第一個命令了，表明初始化 git 倉庫，輸入 git init 以後會提示：

能夠看到初始化成功了，至此 test 目錄已是一個 git 倉庫了。

2.git status

接下來輸入 git status 命令，會有以下提示：

默認就直接在 master 分支，關於分支的概念後面會提，這時最主要的是提示 a.md 文件 Untracked files ，就是說 a.md 文件沒有被跟蹤，尚未提交到 git 倉庫裏，提示可使用 git add 去操做想要提交的文件。

git status 這個命令顧名思義就是查看狀態，這是一個使用最頻繁的命令，建議你們能夠常常輸入這個命令，來查看當前 git 倉庫的一些狀態。

3.git add

上面提示 a.md 文件尚未提交到 git 倉庫裏，這個時候咱們能夠隨便編輯下 a.md 文件，而後輸入 git add a.md ，而後再輸入 git status :

此時提示如下文件 Changes to be committed ， 意思就是 a.md 文件等待被提交，固然你可使用 git rm --cached 這個命令去移除這個緩存。

4.git commit

接着咱們輸入 git commit -m 'first commit' ，這個命令什麼意思呢？ commit 是提交的意思，-m 表明是提交信息，執行了以上命令表明咱們已經正式進行了第一次提交。

這個時候再輸入 git status ，會提示 nothing to commit。

5.git log

此時輸入 git log 命令，會顯示以下內容：

git log 命令能夠查看全部產生的 commit 記錄，從上圖中能夠看到已經產生了一條 commit 記錄，而提交時候的附帶信息叫 'first commit' 。

git log能夠作不少事，好比查看文件的修改信息

git log -s --pretty=oneline filename 查看文件名爲filename的提交記錄

$ git log -s --pretty=oneline yangzai.txt d60e15f257d8d053ae1ef3317ac10bfcc1224dda yangzai3 ce5eb844870a8632bd5656550cb5130537acb245 yangzai2 4ac92c649ef2b80c118541a51745e7de174b670c 衝突測試 29d341e68865438bccdc6c4ac1b3296bffb356fc oldsyang-init 

如上所述，每一行最前面的那一長串數字就是每次提交造成的哈希值，而後就能夠根據這個哈希值，配置git show命令就能夠查看修改的具體信息

$ git show 4ac92c649ef2b80c118541a51745e7de174b670c commit 4ac92c649ef2b80c118541a51745e7de174b670c Author: liuguniang <liuguniang1015@foxmail.com> Date: Mon Aug 7 19:08:16 2016 +0800 衝突測試 diff --git a/yangzai.txt b/yangzai.txt index 190a180..8d38505 100644 --- a/yangzai.txt +++ b/yangzai.txt @@ -1 +1 @@ -123 +456 

6.git add & git commit

看到這裏估計不少人會有疑問，我想要提交直接進行 commit 不就好了麼，爲何先要再 add 一次呢？首先 git add 是先把改動添加到一個「暫存區」，你能夠理解成是一個緩存區域，臨時保存你的改動，而 git commit 纔是最後真正的提交。這樣作的好處就是防止誤提交，固然也能夠將這兩步合併成一步，後面再介紹，建議新手先循序漸進的一步步來。將兩個步驟合併爲：git commit -am 'init'

7.git branch

branch 即分支的意思，分支的概念很重要，尤爲是團隊協做的時候，假設兩我的都在作同一個項目，這個時候分支就是保證兩人協同合做的最大利器。舉個例子，A, B倆人在作同一個項目，可是不一樣模塊，這個時候A新建了一個分支叫a， B新建了一個分支叫b，這樣A、B對代碼作的全部改動都在各自的分支下，互不影響，最終，各自的模塊都完成後，能夠把分支再合併起來。

執行 git init 初始化git倉庫以後會默認生成一個主分支 master ，也是你所在的默認分支，也基本是實際開發正式環境下的分支，通常狀況下 master 分支不會輕易直接在上面操做的，能夠輸入 git branch 查看下當前分支狀況：

若是想在此基礎上新建一個分支，只要執行 git branch a 就新建了一個名字叫 a 的分支，這時候分支 a 跟分支 master 是如出一轍的內容，再輸入 git branch 查看的當前分支狀況：

從上圖能夠看到 master 分支前有個 * 號，即雖然新建了一個 a 的分支，可是當前所在的分支仍是在 master 上，若是想在 a 分支上進行開發，首先要切換到 a 分支上，執行 git checkout a 命令，而後再輸入 git branch 查看下分支狀況：

能夠看到當前所在分支已是a了，這個時候 A 技術人員就能夠盡情的在新建的a分支去進行代碼改動了。

可能有些技術人員會以爲先新建再切換會有些麻煩，下面就提供給你們一個簡便的命令：

git checkout -b a

這個命令的意思就是新建一個a分支，而且自動切換到a分支。

8.git merge

A技術人員在a分支下代碼寫的不亦樂乎，終於他的模塊完成了，而且測試也都經過了，準備要上線，這個時候就須要把他的代碼合併到主分支master上，而後發佈。git merge 就是合併分支用到的命令，針對上述狀況，須要完成兩個步驟，第一步是切換到 master 分支，若是已經在了就不用切換了，第二步執行 git merge a ，意思是把a分支的代碼合併到master分支，不出意外，這個時候a分支的代碼就順利合併到 master 分支上了。爲何說不出意外呢？由於這個時候可能會有衝突而形成合並失敗，留個包袱，後面進階的時候再講。

9.git branch -d

既然有新建分支，那麼必定會有刪除分支，假如這個分支新建錯了，或者a分支的代碼已經順利合併到了 master 分支上，那麼a分支沒用了，須要刪除，這個時候執行 git branch -d a 就能夠把a分支刪除了。

10.git branch -D

有些時候可能會刪除失敗，好比若是a分支的代碼尚未合併到master，執行 git branch -d a 是刪除不了的，會提示a分支還有未合併的代碼，可是若是必定要刪除，那就執行 git branch -D a 就能夠強制刪除a分支。

11.git tag

客戶端開發的時候常常有版本的概念，好比v1.0、v1.1等，不一樣的版本對應不一樣的代碼，因此通常要給代碼加上標籤，這樣假設v1.1版本出了一個新bug，可是又不清楚v1.0是否是有這個bug，有了標籤就能夠順利切換到v1.0的代碼，從新打包測試。

新建一個標籤很簡單，好比 git tag v1.0 就表明在當前代碼狀態下新建了一個v1.0的標籤，輸入 git tag 能夠查看歷史 tag 記錄。

從上圖能夠看出新建了兩個標籤 v1.0、v1.1。

想要切換到某個tag怎麼辦？也很簡單，執行 git checkout v1.0 命令，就順利切換到 v1.0 tag的代碼狀態了。

12 git rm

若是對已經提交的數據文件，想要完全排除，而且之後都再也不提交，操做以下：

1. 使用git rm 文件路勁（這樣的話會同時刪除本地磁盤上的文件，若是不想刪除物理文件請執行，git rm --cache 文件路徑）
2. git add .
3. git commit -m '描述'
4. 將文件名或者文件夾添加到 .gitignore文件裏邊去

以上是一些最基本的Git操做，而且是在本地環境進行操做的，徹底沒有涉及到遠程倉庫，接下來的課程將以遠程 GitHub 倉庫爲例，講解本地如何與遠程倉庫一塊兒同步協做，另外，本節課講述的是最基礎最簡單的Git操做，後續會講解一些Git的高階以及一些Git的酷炫操做。

向Github提交代碼

什麼是SSH？

經過課程「Git速成」的講解，相信你們已經熟悉了本地 Git 倉庫的基本操做，本節課來介紹下如何與遠程倉庫一塊兒協做，向 GitHub 上提交你的第一行代碼！

擁有了一個 GitHub 帳號以後，就能夠自由的 clone 或者下載其餘項目，也能夠建立本身的項目，可是沒法提交代碼。仔細想一想也知道，若是能夠隨意提交代碼，那麼 GitHub 上的項目豈不亂套了，因此提交代碼以前必定是須要某種受權的，而 GitHub 上通常都是基於 SSH 受權的。

那麼什麼是 SSH 呢？

簡單點說，SSH是一種網絡協議，用於計算機之間的加密登陸。目前是每一臺 Linux 電腦的標準配置。而大多數 Git 服務器都會選擇使用 SSH 公鑰來進行受權，因此想要在 GitHub 提交代碼的第一步就是要先添加 SSH key 配置。

生成SSH Key

Linux 與 Mac 都是默認安裝了 SSH ，而 Windows 系統安裝了 Git Bash 應該也是帶了 SSH 的。你們能夠在終端（win下在 Git Bash 裏）輸入 ssh 若是出現如下提示證實你本機已經安裝 SSH， 不然請搜索自行安裝下。

接下來輸入 ssh-keygen -t rsa 命名，意思是指定 rsa 算法生成密鑰，接着連續三個回車鍵（不須要輸入密碼）就會生成兩個文件 idrsa 和 idrsa.pub ，idrsa 是密鑰，idrsa.pub 是公鑰。這兩個文件默認分別在以下目錄裏生成：

Linux/Mac 系統 在 ~/.ssh 下，win系統在 /c/Documents and Settings/username/.ssh 下，都是隱藏文件，相信大家有辦法查看的。

接下來要作的是把 idrsa.pub 的內容添加到 GitHub 上，這樣本地的 idrsa 密鑰跟 GitHub 上的 id_rsa.pub 公鑰進行配對，受權成功才能夠提交代碼。

GitHub上添加SSH Key

首先在 GitHub 上的設置頁面，點擊最左側 SSH and GPG keys ：

而後點擊右上角的 New SSH key 按鈕：

須要作的只是在 Key 那欄把 id_rsa.pub 公鑰文件裏的內容複製粘貼進去就能夠了（上述示例爲了安全粘貼的公鑰是無效的），Title 欄不須要填寫，點擊 Add SSH key 按鈕就ok了。

這裏提醒下，怎麼查看 id_rsa.pub 文件的內容？

Linux/Mac 用戶執行如下命令：

cd ~/.ssh cat id_rsa.pub Windows用戶，設置顯示隱藏文件，可使用 EditPlus ， Sublime或者vscode(本人很是推薦vscode，功能很是強大，微軟出品) 打開復制就好了。

SSH key 添加成功以後，輸入 ssh -T git@github.com 進行測試，若是出現如下提示證實添加成功了

Push & Pull 命令介紹

在提交代碼以前首先了解兩個命令，這兩個命令須要與遠程倉庫配合。

Push ：直譯過來就是「推」的意思，若是你本地代碼有更新，那麼就須要把本地代碼推到遠程倉庫，這樣本地倉庫跟遠程倉庫就能夠保持同步了。

代碼示例： git push origin master

意思就是把本地代碼推到遠程 master 分支。

Pull：直譯過來就是「拉」的意思，若是別人提交代碼到遠程倉庫，這個時候你須要把遠程倉庫的最新代碼拉下來，而後保證兩端代碼的同步。

代碼示例： git pull origin master

意思就是把遠程最新的代碼更新到本地。通常在 push 以前都會先 pull ，這樣不容易衝突（最好強制要求本身這樣）。

提交代碼

添加 SSH key 成功後，就有權限向 GitHub 提交本身的項目代碼了，提交代碼有兩種方法：

（1）Clone本身的項目

此處以我在 GitHub 上建立的 test 項目爲例，執行以下命令：

git clone git@github.com:oldsyang/newtest.git

這樣就把 newtest 項目 clone 到了本地，能夠把 clone 命令理解爲高級的複製，這個時候該項目自己就已是一個git 倉庫了，不須要執行 git init 進行初始化，而且已經關聯好了遠程倉庫，只須要在這個 test 目錄下任意修改或者添加文件，而後進行 commit ，以後就能夠執行：

git push origin master

進行代碼提交，這種是最簡單方便的一種方式。

怎麼獲取項目的倉庫地址呢？以下圖：

（2）關聯本地已有項目

若是本地已經有一個完整的 git 倉庫，而且已經進行了屢次 commit ，這個時候第一種方法就不適合了。

假設本地有個 test2 的項目，須要在 GitHub 上建一個 test 的項目，而後把本地 test2 上的全部代碼 commit 記錄提交到 GitHub 上的 test 項目。

第一步就是在 GitHub 上建一個 test 項目，這個想必你們都會了，就很少講了。

第二步把本地 test2 項目與 GitHub 上的 test 項目進行關聯，切換到 test2 目錄，執行以下命令：

git remote add origin git@github.com:oldsyang/newtest.git

意思是添加一個遠程倉庫，地址是 git@github.com:oldsyang/newtest.git ，而 origin 是給這個項目的遠程倉庫起的名字（能夠隨便取），只不過你們公認的只有一個遠程倉庫時名字就是 origin ，爲何要給遠程倉庫取名字？由於咱們可能一個項目有多個遠程倉庫，好比 GitHub 一個，好比公司一個，這樣的話提交到不一樣的遠程倉庫就須要指定不一樣的倉庫名字。

查看當前項目有哪些遠程倉庫能夠執行以下命令：

git remote -v

接下來，本地的倉庫就能夠向遠程倉庫進行代碼提交了：

git push origin master

此命令就是默認向 GitHub 上的 newtest 目錄提交了代碼，這個代碼是在 master 分支。固然你能夠提交到指定的分支，這個以後的文章再詳細講解。

注意：在提交代碼以前先要設置下本身的用戶名與郵箱，這些信息會出如今全部的 commit 記錄裏，執行如下代碼就能夠設置：

git config —global user.name "newtest"

git config —global user.email "545329979@qq.com"

總結

經過本課時的介紹，終於能夠成功的向 GitHub 提交代碼了，可是相信你們還有不少疑問，好比關於分支的理解與使用，好比 Git 的其餘一些有用的配置，好比怎麼向一些開源項目貢獻代碼，發起 Pull Request 等，以後的系列文章會逐一進行介紹。

Git進階

用戶名和郵箱

經過前面的學習，相信你們已經可使用 Git 管理本身的代碼了，但這些還遠遠不夠，關於Git還有不少知識與技巧，接下來就給你們介紹一些 Git 進階的知識。

在 GitHub 上的每一次commit都會產生一條log，這條log標記了提交人的姓名與郵箱，目的是便於其餘人查看與聯繫提交人，所以，進行提交代碼的第一步就是要設置本身的用戶名與郵箱。執行如下命令：

git config --global user.name "oldsyang"

git config —global user.email "545329979@qq.com"

以上進行了全局配置，若是某一個項目想要使用特定的郵箱，那麼只需切換到相應的項目，將上述代碼中的 --global 參數去除，再從新執行一遍就能夠了。

注意：在 GitHub 上的每次提交理論上都會在主頁的下方產生一條綠色小方塊的記錄，若是確認提交後，沒有綠色方塊顯示，那必定是所提交代碼配置的郵箱與當前 GitHub 上的郵箱不一致，GitHub 上的郵箱能夠到 Setting -> Emails裏查看。

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 

日誌就會變的更有趣

其餘配置

固然還有一些其餘有用的配置，默認狀況下 git 用的編輯器是 vi ，若是不喜歡能夠改爲其餘編輯器，好比 vim 。

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

若是喜歡其餘編輯器可自行搜索配置，前提是本機有安裝。

有些人會疑問怎樣才能讓終端顯示各類顏色，輸入以下命令便可：

git config --global color.ui true

還有些其餘的配置如：

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

以上基本的配置就差很少了，默認這些配置都在 ~/.gitconfig 文件下的，你能夠找到這個文件查看本身的配置，也能夠輸入 git config -l 命令查看。

git ls-tree head #查看當前版本庫裏的文件樹

git ls-files #查看緩存區和版本庫裏的全部文件

diff

diff命令是很經常使用的，在開發過程當中，你們會常常作一些代碼改動，但時間久了不免會忘記作過哪些改動，在提交以前須要確認下，這個時候就能夠用diff來查看到底作了哪些改動，例如，有一個 a.md 的文件，作了一些改動，當輸入 git diff 時，就會看到以下內容：

紅色的部分前面有個 - 表明刪除的內容，綠色的部分前面有個 + 表明增長的內容，從這裏能夠一目瞭然的知道本身到底對這個文件作了哪些改動。

須要注意的是，直接輸入 git diff 只能比較當前文件和暫存區文件差別，什麼是暫存區？就是尚未執行 git add 的文件。

固然除了與暫存區作比較以外，他還能夠有其餘用法，如比較兩次 commit 之間的差別，比較兩個分支之間的差別，比較暫存區和版本庫之間的差別等，具體用法以下：

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

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 進暫存區的文件。

stash

設想一個場景，假設咱們正在一個新的分支作新的功能，這個時候忽然有一個緊急的bug須要修復，並且修復完以後須要當即發佈。技術人員可能會想先把剛寫的一點代碼進行提交就好了，這樣作理論上是沒問題的，可是原則上每次的 commit 都要有實際的意義，目前代碼只是寫了一半，是不建議 commit 的，那麼有沒有一種比較好的辦法，能夠暫時切到其餘分支，修復完bug再切換回來，而且代碼也能保留的？

首先，暫存 commit 代碼：

此時， 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 是清空。

reset

git reset HEAD filename 撤銷文件名filename的全部修改（尚未commit的，只是add進暫存區的）

你們確定在開發的時候，都遇到過想所有回滾到某一個節點，丟棄掉現有的修改，這就reset大有用處，先看一張圖（上圖）

 

 

好比，如今我已經有三次提交記錄了：

先查看git log:
```bash $ git log commit 9f0dc164fad0776ce7ad80a2a064a9840877bf75 Author: oldsyang <545329979@qq.com> Date: Mon Aug 7 10:34:18 2016 +0800 three commit 108cee428009a066fde2f88c79f797da07e51080 Author: oldsyang <545329979@qq.com> Date: Mon Aug 7 10:33:46 2016 +0800 second commit f41d81394a6b524aa35215da926da30d42b64add Author: oldsyang <545329979@qq.com> Date: Mon Aug 7 10:33:25 2016 +0800 init 

如今的需求是回滾到第二次提交的狀態（second），找到第二次提交的哈希值

git reset --hard 108cee428009a066fde2f88c79f797da07e51080 

在執行git log或者git ls-files，就發現回滾到第二次的提交的最原始狀態（至關因而第一次提交完成後的狀態）

那若是如今還想回到three狀態？

先執行 git reflog

$ git reflog
3242www HEAD@{1}: reset: moving to 9f0dc164fad0776ce7ad80a2a064a9840877 bf75 9f0dc16 HEAD@{2}: commit: three 108cee4 HEAD@{3}: commit: second f41d813 HEAD@{4}: commit (initial): init 

再執行 git reset --hard 9f0dc16

$ git reset 9f0dc16 Unstaged changes after reset: 

這樣就整個又回到以前的狀態

merge & rebase

你們都知道 merge 分支是合併的意思，當在一個 featureA 分支開發完一個功能須要合併到主分支 master 上時，只須要進行以下操做：

git checkout master git merge featureA 

其實 rebase 命令也是合併的意思，上面的需求一樣能夠進行以下操做：

git checkout master git rebase featureA rebase 跟 merge 的區別？

能夠理解成有兩個書架，你須要把兩個書架的書整理到一塊兒，第一種作法是 merge ，簡單粗暴，直接空出一塊地方把另外一個書架的書所有放進去，這種作法你能夠知道哪些書是來自另外一個書架；第二種作法就是 rebase ，會對兩個書架的書先進行比較，按照購書的時間從新排序，而後從新放置好，這樣作的好處就是合併以後的書架看起來邏輯清晰，可是很難清楚的知道哪些書來自哪一個書架。

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

解決衝突

假設這樣一個場景，A和B兩位技術人員各自建了兩個分支來開發不一樣的功能，大部分狀況下都會盡可能互不干擾的，可是有一個需求A須要改動一個基礎庫中的一個類的方法，不巧B這個時候因爲業務須要也改動了基礎庫的這個方法，由於這種狀況比較特殊，A和B都認爲不會對地方形成影響，等兩人各自把功能作完了，須要合併的到主分支 master 的時候，假設先合併A的分支，這個時候沒問題，以後再繼續合併B的分支，這個時候就會有衝突了，由於A和B兩我的同時更改了同一個地方，Git 自己不能判斷誰更改的對，可是這個時候他會智能的提示有 conflicts ，須要手動解決這個衝突以後再從新進行一次 commit 提交。接下來，隨便在項目中製造一個衝突作演示：

上圖就是衝突的示例，衝突的地方由 ==== 分出了上下兩個部分，上半部分 HEAD 是當前所在分支的代碼，下半部分是 baiduactivity 分支的代碼，從圖中能夠看出 HEAD 對 gradle 插件進行了升級，同時新增了一個插件，因此很容易判斷哪些代碼該保留，哪些代碼該刪除，咱們只須要移除掉那些老舊代碼，同時也要把那些 <<< HEAD、==== 以及 >>>>>>baiduactivity 標記符號刪除，最後進行一次 commit 就能夠了。

在開發的過程當中，通常都會約定你們寫的代碼儘可能不要彼此影響，以減小出現衝突的可能，可是衝突總歸沒法避免，技術人員們須要瞭解並掌握解決衝突的方法。

 

Git分支經常使用操做

Git 相對於 SVN 最強大的優點就在於「分支」，Git 的分支操做簡單方便，而實際項目開發中團隊合做最依賴的莫過於分支了，關於分支前面的課時也提到過，本課時會詳細講述什麼是分支、分支的具體操做以及實際項目開發中是怎樣依賴分支進行團隊合做的。

1. 什麼是分支？

對於分支這個概念，能夠這樣理解，幾我的一塊兒去旅行，走到一個三岔口，每條路可能有不一樣的風景，你們約定 3 天以後在某地匯聚，而後各自出發了。這三條分叉路就能夠理解爲各自的分支，而你們匯聚的時候就至關於將各自的分支進行了合併。

1. 分支的經常使用操做

一般默認會有一個主分支叫 master ，下面首先來介紹一下關於分支的一些基本操做：

（1）新建一個叫 develop 的分支

git branch develop

注意，新建分支的命令是基於當前所在分支進行的，即以上是基於 mater 分支新建了一個叫作 develop 的分支，此時 develop 分支與 master 分支的內容徹底同樣。例如，有 A、B、C三個分支，各分支內容不一樣，若是當前是在 B 分支，執行新建分支命令，則新建的分支內容與 B 分支相同，同理若是當前在 C 分支，那就是基於 C 分支基礎上新建的分支。

（2）切換到 develop 分支

git checkout develop

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

git checkout -b develop

（3）把 develop 分支推送到遠程倉庫

git push origin develop

若是你遠程的分支想取名叫 develop2 ，執行如下代碼：

git push origin develop:develop2

注意：實際開發管理，建議不要這樣作，這樣會致使很混亂，難管理，建議本地分支與遠程分支名稱要保持一致。

在某些狀況下，你須要對別人的提交（也多是你本身的），進行強制覆蓋

git push --force

（4）查看本地分支列表

git branch

（5）查看遠程分支列表

git branch -r

git branch -a

（6）刪除本地分支

git branch -d develop

git branch -D develop (強制刪除)

（7）刪除遠程分支

git push origin :develop

若是遠程分支有 develop ，而本地沒有，想要將遠程的 develop 分支遷到本地：

git checkout develop origin/develop

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

git checkout -b develop origin/develop

基本的團隊協做流程

通常來講，若是是一我的開發，可能只須要 master、develop 兩個分支就能夠了，平時開發在 develop 分支進行，開發完成以後，發佈以前合併到 master 分支，這個流程不會有大問題。

若是是 三、5 我的，那就不同了，有人以爲也不會有什麼大問題，直接新建 A、B、C 三我的的分支，每人各自開發各自的分支，而後開發完成以後再逐步合併到 master 分支，然而現實狀況是，當某人正在某個分支開發某個功能時，忽然發現線上有一個很嚴重的 bug ，不得不停下手頭的工做優先處理 bug ，而且不少時候多人協做下若是沒有一個規範，很容易產生問題，因此多人協做下的分支管理規範很重要，就像代碼規範同樣重要，接下來就向你們推薦一種分支管理流程 Git Flow。

GitFlow詳細操做

準確的說 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 直接進行修改，直到測試，達到發佈的標準，就能夠把該分支合併到 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 兩個分支。

到目前爲止，你們已經瞭解了這個工具的具體做用，具體安裝與用法就很少介紹了，感興趣的技術人員能夠觀看這篇博客：

http://stormzhang.com/git/2014/01/29/git-flow/

總結

以上就是分享給你們的關於分支的全部知識，一我的你也許感覺不到什麼，可是實際工做中大都以團隊協做爲主，而分支是團隊協做必備技能，Git Flow 是一個很流行的分支管理流程，也是公司團隊內部常用的一套流程，但願你們可以掌握。

分支視頻講解

後續補上

Github常見的幾種操做

有哪些常見的操做？

開源社區最大的魅力是人人均可以參與進去，發揮衆人的力量，讓一個項目更完善，更強壯。那麼就會有人疑問，本身目前尚未能力開源一個項目，可是又想一塊兒參與到別人的開源項目中，該怎樣操做呢？本課時，就來給你們介紹 GitHub 上的一些常見的操做。

下面以 Square 公司開源的 Retrofit 爲例來介紹。

打開連接：https://github.com/square/retrofit ，能夠看到以下的項目主頁：

從上圖能夠看出，一個項目能夠進行的操做主要有兩部分，第一部分包括 Watch、Star、Fork ，這三個操做前面的課時已經介紹過了，這裏不作重複講解。

着重介紹第二部分，分別包括 Code、Issues、Pull requests、Projects、Wiki、Pulse、Graphs。接下來一一進行講解。

（1）Code

表明項目的代碼文件，每一個項目一般都會有對該項目的介紹，只須要在項目的根目錄裏添加一個 README.md 文件就能夠，使用 markdown 語法，GitHub 自動會對該文件進行渲染。

（2）Issues

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

一樣的，你們在使用一些開源項目遇到問題的時候均可以提 Issue，能夠經過點擊右上角的 New Issue 來新建 Issue，添加一個標題與描述就能夠了，這個操做很簡單。

（3）Pull requests

別人開源一個項目，若是咱們想一塊兒參與開發，一塊兒來完善，這就要經過 Pull requests 來完成，簡稱 PR。

（4）Projects

這個是最新 GitHub 改版新增的一個項目，這個項目就是方便將一些 Issues、Pull requests 進行分類，目前爲止該功能被使用的比較少，瞭解一下就好。

（5）Wiki

通常來講，項目的主頁有 README.md 基本就夠了，可是有些時候項目的一些用法很複雜，須要有詳細的使用說明文檔給使用者，這個時候就用到了 Wiki。

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

（6）Pulse

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

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

（7）Graphs

Graphs 是以圖表的形式來展現該項目的一個總體狀況。好比項目的所有貢獻人，commits 的圍度分析，某天代碼提交的頻繁程度等。

（8）Settings

若是一個項目是本身的，那麼你會發現有一個菜單 Settings，這裏包括了對整個項目的設置信息與功能，好比對項目重命名，刪除該項目，關閉項目的 Wiki 和 Issues 功能等，不過大部分狀況下都不須要對這些設置作更改。感興趣的技術人員，能夠自行了解這裏的設置有哪些功能。

以上就包含了一個 GitHub 項目的全部操做，對初學者來講難度最主要的仍是發起 Pull request，不過相信你們看完以後對 GitHub 上一些經常使用的操做應該已經熟悉了，從如今開始，請一塊兒參與到開源社區中來吧，開源社區須要每一個人都貢獻一份力量，這樣纔可以愈來愈強大，也可以對更多的人有幫助！

實踐：提交本身的第一個PR

接下來咱們向項目 newtest 發起 PR操做，說明，必須確保你能夠正常向 GitHub 提交代碼，若是不能夠的話，請仔細觀看前面課時講解的內容。

第一步，登陸你的 GitHub 帳號，而後找到想要發起 PR 的項目，這裏以 newtest 爲例，地址：

https://github.com/oldsyang/newtest

點擊右上角的 Fork 按鈕，該項目就出如今你本身帳號的 Repository 裏。

注意，這個項目本來是屬於 GitHub 帳號 oldsyang 下的，爲了演示，我本身又從新註冊了另外一個帳號叫 yangzaizai 。

Fork 以後，在帳號 yangzaizai 下多了一個 newtest 的項目，以下圖：

從上圖能夠看出 Fork 過來的項目標題底部會顯示一行小字：forked from oldsyang/newtest ，除此以外，項目代碼跟原項目如出一轍，對於原項目來講，至關於別人新建了一個分支而已。

第二步，把該項目 clone 到本地，把本身新增或者改動的代碼保存。

第三步，把本身作的代碼改動 push 到你本身 GitHub 的項目上去。

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

點擊 New pull request 按鈕會看到以下頁面：

這個頁面會自動比較該項目與原有項目的不一樣之處，最頂部聲明瞭是 oldsyang/newtest 項目的 master 分支與你 fork 過來的 yangzaizai/newtest 項目的 master 分支所作的比較。

最底部能夠方便直觀的看到代碼中作了哪些改動，這裏能夠看到我加了一句 Fork from oldsyang !

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

而後就等着項目原做者 review 你的代碼，而且決定會不會接受你的 PR，若是接受，那麼你就已是該項目的貢獻者之一了。

創建組織

在github能夠建立一個組織去協同開發好多項目，操做比較簡單

點擊我的頭像下拉菜單裏的setting選項，

在左側點擊organizations選項，

在右上角點擊 New Organization，而後安裝提示註冊一個組織

建立完成以後就出現詳情頁面

在這個頁面就能夠建立倉庫和邀請成員了，邀請成員後，github會郵件的形式通知被邀請的成員

發現好用的開源項目

關注一些活躍的大牛

通過前面的學習，有技術人員可能會以爲，GitHub 大概瞭解了，Git 也差很少會使用了，但仍是搞不清 GitHub 如何幫助你們提高工做效率，其實 GitHub 最重要的一個做用就是發現全世界最優秀的開源項目，你沒事的時候刷刷微博、知乎，別人沒事的時候刷刷 GitHub ，看看最近有哪些流行的項目，長此以往，差距就會愈來愈大，那麼如何發現優秀的開源項目呢？本課時就來給你們介紹一下。

GitHub 主頁有一個相似微博的時間線功能，全部你關注的人的動做，好比 star、fork 了某個項目都會出如今你的時間線上，這種方式適合我這種比較懶的人，不用主動去找項目，這也是我天天獲取信息的一個很重要的方式。不知道怎麼關注這些人？那麼很簡單，關注我 oldsyang ，以及我 GitHub 上關注的一些大牛，基本就差很少了。

Trending

點擊下圖的 Explore 菜單到「發現」頁面

點擊下圖的 Trending 按鈕

Trending 直譯過來是趨勢的意思，也就是說從這個頁面能夠看到最近一些熱門的開源項目，這個頁面是不少人主動獲取一些開源項目最好的途徑，能夠選擇「當天熱門」、「一週以內熱門」和「一月以內熱門」來查看，而且還能夠分語言類來查看，好比你想查看最近熱門的 Android 項目，那麼右邊就能夠選擇 Java 語言。 這個頁面推薦你們每隔幾天就去查看一下，主動發掘一些優秀的開源項目。

Search

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

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

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

android http stars:>1000

固然還有些其餘小技巧，這裏就很少介紹了。

若是使用 Google 瀏覽器，想要搜索 GitHub 上的結果，能夠在前面加 GitHub 關鍵字，好比 輸入 github python request ，每一個關鍵字用空格隔開，基本也是想要的結果，只是否是單純的按照 star 數來排序的。

GitHub 上優秀開源項目真的是不少，就不一一推薦了，授人以魚不如授人以漁，請你們自行發掘本身須要的開源項目吧，無論是應用在實際項目上，仍是對源碼的學習，都是提高本身工做效率與技能的很重要的一個渠道，總有一天，你會忽然意識到，原來不知不覺你已經走了這麼遠。