git/github的使用
內容最后更新時間：2018-08-10
以下內容是我在收集而來，再經過自己的經驗修改而成，希望對你有用（在不斷的更新中）
歡迎來到Github
初識Github
版本控制的介紹
熟練使用Git/Github是互聯網公司程序員的必備技能之一。當開發中遇到困難或者職業技能遇到瓶頸時，Github簡直是相見恨晚的利器，身為一線開發者，如果沒有接觸過Github，的確是一大損失。因此，從今天開始，本課程就將帶領大家敲開Github的大門。
確切的說，Github是由Chris Wanstrath、PJ Hyett 與 Tom Preston-Werner 三位開發者共同創辦的一家公司，于2008年4月10日成立于舊金山，主要提供基于git的版本托管服務。一經上線，它的發展速度驚為天人，截止目前，Github 已經發展成全球最大的開（同）源（性）社區。Logo如圖所示。
Github與Git的關系
Github ≠ Git，很多人以為 Github 就是 Git，其實這是一個理解誤區。
Git 是一款免費、開源的分布式版本控制系統，由著名的 Linux 發明者 Linus Torvalds 開發。說到版本控制系統，大多數人都用過 SVN ，Git 是新時代的產物，如果你還在用 SVN 來管理代碼，那就真的有些落伍了。不管是學習 Github ，還是以后想從事編程行業，Git 都可以算是一項必備技能，所以，建議大家可以自學下 Git ，后面的課程中也會向大家推薦一些適合新手學習Git的資料。
Github 主要是提供基于 git 的版本托管服務，也就是說，現在 Github 上托管的所有項目代碼都是基于 Git 來進行版本控制的，所以 Git 只是 Github 上用來管理項目的一個工具而已，Github 的功能可遠不止于此！
Github的影響力
為什么說 Github 是全球最大的開源社區了，下面讓我們一一舉證：
全球頂級科技公司紛紛加入 Github ，并貢獻他們自己的項目代碼
Google: Github.com/google
蘋果: Github.com/apple
Facebook: Github.com/facebook
Twitter：Github.com/twitter
微軟：Github.com/microsoft
Square：Github.com/square
阿里：Github.com/alibaba
...
全球頂級開源項目都優先選擇在 Github 上開源
Linux：Github.com/torvalds/li…
Rails：Github.com/rails/rails
Nodejs：Github.com/nodejs/node
Swift：Github.com/apple/swift
CoffeeScript：Github.com/jashkenas/c…
Ruby：Github.com/ruby/ruby
...
全球頂級編程大牛加入Github
Linux 發明者 Linus Torvalds：Github.com/torvalds
Rails 創始人 DHH：Github.com/dhh
被稱為「Android之神」的 JakeWharton：Github.com/JakeWharton， 你們用的很多開源庫如 ButterKnife、OkHttp、 Retrofit、 Picasso、ViewPagerIndicator 等都是出自他之手！
其他就不一一列舉了，Github 上活躍的很多是 Google 、Square、阿里等公司的員工，有些甚至還是Google Android Team組的，所以在這里你可以接觸到全球頂級編程大牛！
Github有什么用？
1.學習優秀的開源項目
開源社區一直有一句流行的話叫「不要重復發明輪子」，某種意義上正是因為開源社區的貢獻，我們的軟件開發才能變得越來越容易，越來越快速。試想你在做項目時，如果每一模塊都要自己去寫，如網絡庫、圖片加載庫、ORM庫等等，自己寫的好不好是一回事，時間與資源是很大的成本。對于大公司可能會有人力與資源去發明一套自己的輪子，但是對于大部分互聯網創業公司來說時間就是一切。而且你在使用開源項目的過程也可以學習他們優秀的設計思想、實現方式，這是最好的學習資料，也是一份提升自己能力的絕佳方式！
2.多人協作
如果你想發起一個項目，比如翻譯一份不錯的英文文檔，覺得一個人的精力不夠，所以你需要更多的人參與進來，這時候 Github 是你的最佳選擇，感興趣的人可以參與進來，利用業余時間對這個項目做貢獻，然后可以互相審核、合并，簡直不要太棒！
3.搭建博客、個人網站或者公司官網
這個就不用多說了，現在越來越多的博客都是基于 Github Pages 來搭建的了，你可以隨心所欲的定制自己的樣式，可以給你博客買個逼格高的域名，再也不用忍受各大博客網站的約束與各式各樣的廣告了！
4.寫作
如果你喜歡寫作，而且基于 Markdown， 并準備出版書籍，那么推薦你用 Gitbook ，技術寫作人的最愛！
5.個人簡歷
如果你有一個活躍的 Github 賬號，上面有自己不錯的開源項目，還經常給別的開源項目提問題，push 代碼，那么你找工作將是一個非常大的優勢，現在程序員的招聘很多公司都很看中你 Github 賬號，某種意義上 Github 就可以算是你的簡歷了。而且不僅國內，很多國外的科技公司都會通過 Github 來尋找優秀的人才，比如我甚至通過 Github 收到過 Facebook 的邀請郵件！
6.加入 Github
讀完這篇文章，是否你已經蠢蠢欲動了，從現在開始，立刻、馬上去注冊個 Github 「Github.com」，去體驗一番，不會用不要緊，接下來我們會有一系列的課程，來教你學會使用 Github ！
加入Github
注冊Github
在學習本節課程之前先解答下大家比較關心的兩個問題：
1.Github 需要翻墻嗎？
答案是不需要翻墻的。對于國內用戶，Github 在2013年之前總是訪問不穩定，2013年初的時候最為嚴重，一度被封。當時李開復老師因為此事，特公開發布抗議 Github 被封的微博；此外大量使用 Github 的程序員也是長期深受訪問限制的困擾，很多人對此事怨聲載道。因此，李開復老師的公開發言，在IT界產生了共鳴，大家紛紛在微博上轉發譴責，算是當時的重大事件了，后來因為此事反響劇烈，沒過幾天 Github 就可以正常訪問了，為此，我們應該感謝李開復老師敢于站出來的勇氣。可以說，如果沒有 Github ，中國的編程水平起碼要倒退好幾年！
由于Github 的影響力較大，因此，也成為了各種黑客攻擊的對象，所以，偶爾也會有宕機訪問不了的情況，但是好在不會被封，大家也不必擔心。訪問 Github 不用翻墻，只是可能訪問速度稍慢些，另外為了維護一個和諧的環境，在這里呼吁大家不要在 Github 上發表任何關于政治的言論與文章，在 Github 上我們只是單純的技術交流，無關政治，在復雜的大環境下，希望 Github 永遠是程序員們的一片凈土！
2.英語差，0基礎能學會嗎？
不少人會提出疑問：Github 是全英文的，英文不好怎么辦？請放心，Github 雖然是全英文，但是對英語水平的要求并不是很高，都是些簡單的詞匯，你會覺得很難，只是因為對英文網站反射性的抵觸而已，相信自己，只要認真學習本課程，你一定會慢慢愛上使用Github的！
在清楚了上述兩個問題后，讓我們開始注冊 Github 吧。
首先在 Github 官網（Github.com/）「How people build software · Github」上注冊「Sign Up」一個賬號，注冊頁面如下：
此處比較簡單，跟一般的網站注冊流程一樣，需要填用戶名、郵箱、密碼，需要注意的是填寫用戶名時，請不要過于隨意，這個名字是你以后常用的用戶名，也強烈建議在各大社交賬號都使用同一個用戶名，這樣識別度較高，比如博客域名、Github、知乎等其他社交賬號 ID 都統一處理，下面，來給自己取個好的用戶名吧。
填好用戶名、郵箱、密碼，接下來到這一步：
這個是什么意思呢？Github 有兩種，一種是公開，另一種是私有。前者是免費的，所創建的項目是開放的，所有人都能看得到；后者是收費的，企業用戶較多，通常情況下企業會使用 Github 的私有倉庫托管自己的項目，這也是 Github
認識Github
注冊成功之后會來到 Github 的主頁面：
新注冊用戶，由于沒有自己的項目，沒有關注的人，所以只有一個導航欄。
導航欄，從左到右依次是 Github 主頁按鈕、搜索框、PR、Issues、Gist（這些概念后面會講解）、消息提醒、創建項目按鈕、我的賬號相關。
我的 Timeline，這部分可以理解成微博，關注過的一些人的活動會出現在這里，例如，你們關注我了，那么以后我 star、fork 了某些項目就會出現在你的時間線里。
我的項目，這部分就不用說了，如果你創建了項目，就里就可以快捷訪問。
Github主頁介紹
點擊下圖的 Your profile 菜單進入到你的個人 Github 主頁。
以我的 Github 主頁為例：
圖片標注的已經很詳細了，當然新的賬號沒有這么豐富，因為什么也沒做過，但是如果做全了基本上就會看到跟我一樣的效果。
設置你的Github
如果是新注冊的 Github 賬號，是不是覺得很簡陋？雖然沒有自己的項目，但是第一步起碼要完善自己的信息，點擊如下的 Settings 菜單：
通過設置頁面設置基本信息：
頭像、Name 建議要設置一個常用的，這兩個很有識別性，公開的郵箱也要設置一個，這樣那些企業、獵頭就通過這個公開郵箱去聯系你，友情提醒：綁定郵箱最好是 Gmail 郵箱，其次是 foxmail、163 的郵箱，不推薦使用 QQ 郵箱。
Github基本概念
認識了 Github 的基本面貌之后，接下來需要了解一些 Github 的基本概念，這些概念是你經常會接觸并遇到的。
Repository 倉庫的意思，即你的項目，如果你想在 Github 上開源一個項目，那就必須要新建一個 Repository ，如果你開源的項目多了，你就會擁有多個 Repositories 。
Issue 問題的意思，舉個例子，就是你開源了一個項目，別人發現你的項目中有bug，或者哪些地方做的不夠好，他就可以給你提個 Issue ，即問題，提的問題多了，也就是 Issues ，然后你看到了這些問題就可以去逐個修復，修復ok了就可以一個個的 Close 掉。
Star 這個好理解，就是給項目點贊，但是在 Github 上的點贊遠比微博、知乎點贊難的多，如果你有一個項目獲得100個star都算很不容易了！
Fork 這個不好翻譯，如果實在要翻譯我把他翻譯成分叉，什么意思呢？你開源了一個項目，別人想在你這個項目的基礎上做些改進，然后應用到自己的項目中，這個時候他就可以 Fork 你的項目，這個時候他的 Github 主頁上就多了一個項目，只不過這個項目是基于你的項目基礎（本質上是在原有項目的基礎上新建了一個分支，分支的概念后面會在講解Git的時候說到），他就可以隨心所欲的去改進，但是絲毫不會影響原有項目的代碼與結構。
Pull Request 發起請求，這個其實是基于 Fork 的，還是上面那個例子，如果別人在你基礎上做了改進，后來覺得改進的很不錯，應該要把這些改進讓更多的人收益，于是就想把自己的改進合并到原有項目里，這個時候他就可以發起一個 Pull Request（簡稱PR） ，原有項目創建人就可以收到這個請求，這個時候他會仔細review你的代碼，并且測試覺得OK了，就會接受你的PR，這個時候你做的改進原有項目就會擁有了。
Watch 這個也好理解就是觀察，如果你 Watch 了某個項目，那么以后只要這個項目有任何更新，你都會第一時間收到關于這個項目的通知提醒。
Gist 有些時候你沒有項目可以開源，只是單純的想分享一些代碼片段，這個時候 Gist 就派上用場了！
創建自己的項目
點擊頂部導航欄的 + 可以快速創建一個項目，如下圖：
創建一個項目需要填寫如上的幾部分：項目名、項目描述與簡單的介紹，你不付費沒法選擇私有的，所以接著只能選擇 public 的，之后勾選「Initialize this repository with a README」，這樣你就擁有了你的第一個 Github 項目：
可以看到這個項目只包含了一個 README.md 文件，但是它已經是一個完整的 Git 倉庫了，你可以通過對它進行一些操作，如watch、star、fork，還可以 clone 或者下載下來。
這里提一下 README.md ，Github 上所有關于項目的詳細介紹以及 Wiki 都是基于 Markdown 的，甚至之后在 Github 上搭建博客，寫博客也是如此，所以如果還不懂 Markdown 語法的，建議先去學習下。推薦一篇學習 Markdown 的文章給你們：
獻給寫作者的 Markdown 新手指南
總結
本節課主要對Github 的基本概念進行了簡單的講解，此時便已經正式加入 Github 這個大家庭了，接下來的課程會有更深入的文章介紹 Git、介紹對項目的常用操作、介紹如何給開源項目提交代碼、介紹如何協同合作等。
版本控制的基礎 Git
Git速成
什么是Git
通過前面的學習了解到GitHub 是基于 Git 的，所以也就意味著 Git 是基礎，如果不會使用 Git ，那么接下來會完全繼續不下去，因此，今天的課程就來說說 Git ，本課程先介紹一些最基本的、最常用的一些 Git 知識，爭取讓你迅速掌握 Git 。
Git 是 Linux 發明者 Linus 開發的一款新時代的版本控制系統，那么到底什么是版本控制系統呢？網上各種詳細的介紹，大多枯燥乏味，對于新手很難理解，這里只舉幾個例子來幫助大家理解。
熟悉編程的人都知道，在軟件開發中源代碼是最重要的，那么對源代碼的管理也就變得更加重要了，以下幾種情況在開發中最為常見：
- 在開發程序時，為了防止代碼丟失，需要在本地機器與遠程服務器各存放一份，并且還需要有一套機制使本地可以與遠程同步；
- 開發中通常是幾個人做同一個項目，要對同一份代碼做更改，這個時候既需要大家互不影響，又需要各自可以同步別人的代碼；
- 開發的過程中免不了有bug，有時候剛發布的功能就出現了嚴重的bug，這個時候需要緊急對代碼進行還原；
- 隨著版本迭代的增多，作為開發者需要清楚的知道每一個歷史版本的代碼更改記錄，甚至知道每個人歷史提交代碼的情況。
以上的這些情況，都是版本控制系統可以解決的問題。版本控制實際上就是一種記錄一個或若干文件內容變化，以便將來查閱特定版本修訂情況的系統，對于軟件開發領域來說版本控制是最重要的環節，而 Git 毫無疑問是當下最流行、最好用的版本控制系統。
2.Git 安裝
Git 是一個版本控制系統，也可以理解為一個工具，跟 Java 類似，使用之前必須先進行下載安裝， Mac 筆記本上其實系統自帶了 Git ，不過這里統一提供各平臺的安裝方式，這部分就不過多介紹，相信大家可以搞定。
- Mac：sourceforge.net/projects/gi…
- Windows：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
如果對已經提交的數據文件，想要徹底排除，并且以后都不再提交，操作如下：
以上是一些最基本的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 算法生成密鑰，接著連續三個回車鍵（不需要輸入密碼）就會生成兩個文件 id_rsa 和 id_rsa.pub ，id_rsa 是密鑰，id_rsa.pub 是公鑰。這兩個文件默認分別在如下目錄里生成：
Linux/Mac 系統 在 ~/.ssh 下，win系統在 /c/Documents and Settings/username/.ssh 下，都是隱藏文件，相信你們有辦法查看的。
接下來要做的是把 id_rsa.pub 的內容添加到 GitHub 上，這樣本地的 id_rsa 密鑰跟 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 <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 +0800threecommit 108cee428009a066fde2f88c79f797da07e51080 Author: oldsyang <545329979@qq.com> Date: Mon Aug 7 10:33:46 2016 +0800secondcommit f41d81394a6b524aa35215da926da30d42b64add Author: oldsyang <545329979@qq.com> Date: Mon Aug 7 10:33:25 2016 +0800init 復制代碼現在的需求是回滾到第二次提交的狀態（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 是當前所在分支的代碼，下半部分是 baidu_activity 分支的代碼，從圖中可以看出 HEAD 對 gradle 插件進行了升級，同時新增了一個插件，所以很容易判斷哪些代碼該保留，哪些代碼該刪除，我們只需要移除掉那些老舊代碼，同時也要把那些 <<< HEAD、==== 以及 >>>>>>baidu_activity 標記符號刪除，最后進行一次 commit 就可以了。
在開發的過程中，一般都會約定大家寫的代碼盡量不要彼此影響，以減少出現沖突的可能，但是沖突總歸無法避免，技術人員們需要了解并掌握解決沖突的方法。
圖形工具
圖形工具不建議使用，太low，而且也不直觀，這里就不介紹了
團隊合作利器：git分支詳解
Git分支常用操作
Git 相對于 SVN 最強大的優勢就在于「分支」，Git 的分支操作簡單方便，而實際項目開發中團隊合作最依賴的莫過于分支了，關于分支前面的課時也提到過，本課時會詳細講述什么是分支、分支的具體操作以及實際項目開發中是怎樣依賴分支進行團隊合作的。
對于分支這個概念，可以這樣理解，幾個人一起去旅行，走到一個三岔口，每條路可能有不同的風景，大家約定 3 天之后在某地匯聚，然后各自出發了。這三條分叉路就可以理解為各自的分支，而大家匯聚的時候就相當于將各自的分支進行了合并。
通常默認會有一個主分支叫 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 分支，這個流程不會有大問題。
如果是 3、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 開源地址：[github.com/nvie/gitflo…]
簡單來說，這個工具會幫大家節省很多步驟，例如，當前處于 master 分支，如果想要開發一個新的功能，第一步切換到 develop 分支，第二步新建一個以 feature 開頭的分支名，有了 Git Flow 直接如下操作就可以完成了：
git flow feature start A
這個分支完成之后，需要合并到 develop 分支，進行如下操作：
git flow feature finish A
如果是 hotfix 或者 release 分支，會自動合并到 develop、master 兩個分支。
到目前為止，大家已經了解了這個工具的具體作用，具體安裝與用法就不多介紹了，感興趣的技術人員可以觀看這篇博客：
stormzhang.com/git/2014/01…
總結
以上就是分享給大家的關于分支的所有知識，一個人你也許感受不到什么，但是實際工作中大都以團隊協作為主，而分支是團隊協作必備技能，Git Flow 是一個很流行的分支管理流程，也是公司團隊內部經常使用的一套流程，希望大家能夠掌握。
分支視頻講解
后續補上
Github常見的幾種操作
有哪些常見的操作？
開源社區最大的魅力是人人都可以參與進去，發揮眾人的力量，讓一個項目更完善，更強壯。那么就會有人疑問，自己目前還沒有能力開源一個項目，但是又想一起參與到別人的開源項目中，該怎樣操作呢？本課時，就來給大家介紹 GitHub 上的一些常見的操作。
下面以 Square 公司開源的 Retrofit 為例來介紹。
打開鏈接：github.com/square/retr… ，可以看到如下的項目主頁：
從上圖可以看出，一個項目可以進行的操作主要有兩部分，第一部分包括 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 為例，地址：
github.com/oldsyang/ne…
點擊右上角的 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 上優秀開源項目真的是很多，就不一一推薦了，授人以魚不如授人以漁，請大家自行發掘自己需要的開源項目吧，不管是應用在實際項目上，還是對源碼的學習，都是提升自己工作效率與技能的很重要的一個渠道，總有一天，你會突然意識到，原來不知不覺你已經走了這么遠。
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的git/github的使用的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用 icon 字体图标出现小方块问题
- 下一篇： 第九章：路由网关(Zuul)的使用