標籤：

怎樣使用 GitHub？

11-24

具體的使用方法和相關解釋英語不好一點看不明白

作為一個文科妹子，我在看過幾乎所有熱門 github 教程之後依舊一頭霧水，在近半年的摸索中終於明白啦~新年初，把自己純小白的學習經驗分享一下吧！

#什麼是 Github ？
必須要放這張圖了！！！

（圖片來源GitHub 是怎樣的一個存在？ - Deep Reader 的回答）

Git 是由 Linux 之父 Linus Tovalds 為了更好地管理linux內核開發而創立的分散式版本控制／軟體配置管理軟體。

好吧，我相信看到這裡你已經暈了，這也是我一開始看那些所謂經典教程的感受。寫這些教程的人都是幾年以上的程序員呀，他們往往直接就告訴你所有命令的含義或者整個體系。

專家盲點（expert blind spot）就是對一個事物知道的越多，就越發不記得「不知道這個事」的情形。

簡單來說，Git 是一個管理你的「代碼的歷史記錄」的工具。

我不是程序員為什麼要學這個啊啊啊！又不要管理代碼們！

別急，雖然 github 學習門檻高，一會你就知道為什麼人人都應該會這個啦！

----------------------------
學習步驟

##註冊安裝
去官網註冊一個賬號（這個你應該會，恩就不放鏈接了）
然後，下載一個GitHub Desktop mac客戶端是最方便的啦！（命令行什麼的真的是會越來越暈！先別管他們！）

假設33（珊姍就是我啦）、小四和你三個人一起寫一本小說（澄清一下，並沒有黑任何人的意思，恩！），暫且叫做...《夢裡花落愛吃土時代》
--
圖（腦補）
--
(⊙v⊙)嗯！終於可以正式開始了！

#step1:創建新項目
我們三個人在不同的城市要遠程共同寫一本書，要有一個漂亮的筆記本吧？

「repositories」就是你的筆記本們。你只需知道 Repository 是個放項目的地方就行。有時候會出現 Repositories，是多個 Repository 的意思。

**fork**
如果你不想新建一個筆記本，看到小四之前寫過一個好到炸裂的文章，想把他的直接全部偷過來，修改修改就成你自己的文章了，這應該怎麼辦呢？
github 還提供了一個很贊的功能叫做 fork ，你只需要點擊這個神奇的按鈕，就可以把他的「筆記本」變成你自己的啦！任意修改都可以哦~

#step2：把「筆記本」克隆到本地
「筆記本」在雲端，你要把它摘下來放到自己的電腦上寫小說才方便呀，在這裡我們叫「clone」是不是很形象？步驟如圖：

或者是直接去我們的客戶端

#step3：可以開始寫作啦！
你的筆記本里已經自動有一個文檔了，這個時候讓我們回到網頁版[微笑臉]
你只需要在 web 端點開這個README.md可以開始在裡面寫你的小說了。

或者直接點開剛剛 clone 到電腦上的文件夾直接在裡面寫。
ps:需要注意的是，文本支持 markdown 格式，可以先參考這個獻給寫作者的 Markdown 新手指南。

#step4:上傳你寫的小說
在本地寫完之後你要上傳到雲端讓我和小四都能看見你寫出什麼幺蛾子了吧？
回到客戶端，你發現有變化！！！

沒錯，在你頭像旁邊給你這次提交內容起一個名字，以後如果再次尋找的時候會很方便。然後點下面的 Commit to master，還有右上角的 Sync 就好啦！

#step5：回退到之前的版本
夜深人靜的時候，我趁著你們都在睡覺把小說的結局偷偷地改成女主死掉了！
你醒來覺得我這結局改的也太悲傷了，完全不能接受！結局必須要和之前那樣王子公主幸福的生活在一起的 happy ending！
問題又來了，怎麼退回到我修改結局之前的 happy ending？

還是剛剛那個客戶端，選擇History 然後點擊小齒輪，選擇瀟洒地點 roll back to this commit！
你又回到happy ending的狀態啦！！

#step6：
小四寫了一章華麗無比的番外，你要更新本地的小說和他寫的保持一致怎麼辦？
git pull

-----------
好了，知道這些基本操作入門應該夠了，我們來回顧一下（不要嫌棄我的畫工啊喂！）

入門初期迅速得到一些正反饋對於學習一門新技能來說實在是太重要了！尤其是編程這麼炫酷的事情！
所以先不要管什麼複雜的 issue 呀 wiki 呀亂七八糟的操作，按照上面的一步一步來，如果遇到什麼問題 google 之，一般都會解決的。

有一個段子不就是說，當你遇到問題去找最高級的工程師，他們一般都會直接 google 嗎？而且自帶的幫助手冊也是解決問題的好辦法，比如你要新建一個 branch=》Create a new branch with git and manage branches · Kunena/Kunena-Forum Wiki · GitHub

這種遇到問題先自己嘗試解決的小技巧，也是我自從學編程以來最大的收穫。

------------------------

#除了寫代碼你還可以用 github 做什麼？

回到文章開頭，我又不是程序猿不用寫代碼玩這個幹啥？

你有沒有碰到過團隊里幾個人共同協作寫一個文檔的時候？或者說需要反覆修改的東西？比如最簡單的寫論文，用 word 保存一個一個版本 e-mail 給 boss？下次再找上次修改了什麼地方簡直要死啊有木有！！！

相信你看了我的遠程協作寫小說的例子應該已經明白了， github 說白了就是一個「版本控制工具」。我們所謂的「回退」到歷史記錄，隨時查看更改了什麼地方，利用這個功能可以做的事情簡直太多啦！

就像 github 其中一位創始人[Chris](defunkt (Chris Wanstrath) · GitHub)也詳細描述了[GitHub初創的前因後果](Startup Riot 2009 Keynote 路 GitHub)，他說道：

Do whatever you want.

所以不是程序猿可以用這個來做什麼呢？
1、寫書
和 33 一起寫小說的例子，還記得吧？幾個人你一章我一章共同修改一本書，或是幾個出版社的編輯對新書進行校對，利用這個神器就可以隨時看到哪裡出現了問題和更改。如果想自己寫書的話 gitbook 也是不錯的選擇（又是一個坑。。）

2、寫文檔神器
身為科研狗、產品狗、射雞濕的你，是不是經常寫文檔？一個成熟的文檔可能會有好幾個版本，需要不斷地迭代，然後不斷提交給老闆看哪裡需要修改。在不同版本間自如切換就要用到git branch和git rebase了。
想想看，用 git 的分支管理不比拷貝粘貼更方便嗎？

3、健身
有個哥們為了激勵自己健身把每日計劃都放上去了，還可以邀請其他人一起來相互監督！（我才不會說我自己也開了一個呢哈哈哈）
hoosin/EveryDaySport · GitHub

4、找男票
沒錯，看這個項目！利用眾包的形式一起羅列男友條件的 list 然後試圖自己開發出一個男票233333
YixuanFranco/YourBoyfriend · GitHub
有人評論問我用這個找到男票了嗎？
統一回復：
並！沒！有！

5、用GitHub搭建博客、個人網站或者公司官網

一個有自己域名的獨立博客，是不是很帥？！

GitHub本身提供免費的託管服務，又提供了貼心的 Pages 功能，可以綁定你自己的域名，免費、高效、不限流量，做一個個人頁面綽綽有餘。

Jekyll 的教程和我自己的博客會稍後放出。。（先給自己挖個坑）


6、用GitHub協作翻譯

蘋果官方發布的各種官方手冊，比如最近開源的 Swift numbbbbb/the-swift-programming-language-in-chinese · GitHub 就是國內一個自發組織起來的團隊，30多個人用9天時間即將翻譯和校對工作全部完成，他們每人都還有自己的事情，上班、上線、創業，這麼大的工作量在以往簡直是不可能完成的任務！


7、項目管理

GitHub最初是為了開發的管理而生，當然也就具備了項目管理的潛質，特別是與開發密切聯繫的項目中，它的優勢盡顯。比如這篇文章介紹了如何使用GitHub結合 Trello 等其它工具進行項目管理：使用GitHub進行團隊合作。當然，GitHub還是很偏重開發的管理，一般的項目管理還是適合使用 wortile 之類的產品。


7、政府文件？
之前看到一個知乎回答說：日本政府把憲法放上去了，德國政府也做過類似的事：German Federal Law Now on GitHub。除了德日之外，英美在 GitHub 上也有很多公眾服務：英國政府多達 10 頁的項目目錄：Government Digital Service · GitHub 其中很多是政府項目的源代碼或者設計原則之類。芝加哥的公開地理信息：Forking your CityNew York Open City： City of New York 路
（原諒我找不到這個回答了，歡迎補充）

8、科研項目及數據
較早的arXiv、PLoS之外，較有氣象的可以推薦mendeley、開放期刊目錄
教育方面：

  • OpenStudy：一個社會性學習網路，通過互助來更好地學習，主題涉及到計算機、數學、寫作等。
  • openhatch: 通過練習、任務等幫助新手更好地進入開源社區

9、個人簡歷

GitHub上的代碼無法造假，也容易通過你關注的項目來了解你的知識面的寬度與深度。現在越來越多知名公司活躍在GitHub，發布開源庫並招募各類人才，例如：Facebook、Twitter、Yahoo ...

開始有了第三方網站提供基於GitHub的人才招聘服務，例如：

  • GitHire:通過它，可以找出你所在地區的程序員。
  • Gitalytics.com：通過它，能評估某位程序員在GitHub、LinkedIn、StackOverflow、hackernews等多個網站的影響力。

甚至專門有一個項目就是自動根據你的 GtiHub 公開項目創建個人簡歷：
我們可以使用 Git 以及 GitHub 做哪些事情？ - Kane Blueriver 的回答

10、設計資源庫（重點來了！！！）
做 ppt 不知道到哪裡去找高質量美圖？
最近半年初入設計圈，收集了不少 bookmark 想在年底來一個總結。 於是自己創建了這個Design- Resource List 項目，旨在讓更多的設計師找資源變得有章可循。

先更新一部分，大概還有200多個還沒放過來。。（吐血） 所以，歡迎大家也推薦自己收藏的資源，加入這個項目並一起持續更新么么噠 ：）
timmy3131/design-resource · GitHub

11、Explore · GitHub 更多好玩的內容等你自己發現哦
你在 GitHub 上看到過的最有意思的項目是什麼？ - 調查類問題

-------------------------------------
#更多高階教程：
如果你已經不滿足於上面的基礎知識了，歡迎探索更高級的玩法！
1、GitCafe / Help
2、[git簡明指南](git - the simple guide)牆裂推薦！漫畫的形式很形象（恩我承認比我畫的好看多了）

3、在線交互學習 github 的網站Learn Git Branching 這個也很好玩~

4、[GitHub自身的官方博客](The GitHub Blog · GitHub)

5、git-flow 備忘清單

入門書籍推薦：
GitHub入門與實踐 (豆瓣)比較基礎
Pro Git (豆瓣) 更高級的教程，很全面！

對了對了，還有陽志平老師的兩篇非常全面的舊文（這麼稱呼好生疏啊2333）
如何高效利用GitHub
Git與Github入門資料

------------------------
( ⊙ o ⊙ )啊！知乎居然還不支持 markdown 心好累。。

祝大家新年快樂。
ps：有朋友問我真的用 github 來寫小說嗎？
o(╯□╰)o只是舉例子啊！方便大家理解而已...
還是會寫一點點代碼的(*/ω＼*)

歡迎各位程序員哥哥們糾錯呀，別忘了點贊贊贊！！！！！

這是我在學習github的時候順便寫的教程，簡單明了。

2017.7.19更新

---------------------------------

添加新舊對比圖

2016.9.24更新

-----------------------------------

在使用技巧中添加一條查看代碼比例。

2016.8.28更新

-----------------------------------

添加GitHub for Windows使用教程（四）

主要是一些github使用技巧。

博客地址

GitHub for Windows使用教程（一）

GitHub for Windows使用教程(二)

GitHub for windows使用教程（三）

Github for windows使用教程(四)

如若有錯，還望指正。

如果你還不知道什麼是git，只知道github，但是還不會用，我想這個教程會幫助你。

前言

鑒於網上目前的教材都太落後，github for windows已經更新了多個版本，好多界面都發生了變化，所以來寫這個教程。目的是為了幫助和我一樣初學github，但是苦於找不到教程的同學，為了寫最詳細的教程。配備了大量的圖文介紹。該教程是基於GitHub for windows (3.0.17.0)

註：

由於教程為 3.0.17.0 ，之後github對客戶端進行了新版的更新，這裡的圖為新版與舊版對比。希望可以給大家帶來幫助。

什麼是Github

說到什麼事github，我們先看wikipedia的描述「GitHub是一個利用Git進行版本控制、專門用於存放軟體代碼與內容的共享虛擬主機服務。它由GitHub公司（曾稱Logical Awesome）的開發者Chris Wanstrath、PJ Hyett和Tom Preston-Werner使用Ruby on Rails編寫而成。」

準備工作

  1. 下載github for windows，安裝這裡不贅述。
  2. 註冊github賬號

  1. 登陸到github for windows。

準備工作都完了，我們開始正式學習。^_^

創建第一個代碼庫

認識界面

github for windows的界面非常清爽，的確符合geek的性質，個人表示非常喜歡。 我們來建立第一個倉庫，點擊左上角的+號，初次建立他會有一圈圈的漣漪，非常漂亮哦。 打開之後有三個選項，Add，Create，Clone。 我們分別來介紹一下這三個功能。

Add功能

如果本地有工程，就可以使用Add添加

Clone功能

這個功能其實最好理解了，克隆這名字通俗易懂好理解。 如何使用Clone功能呢？ 就是將在瀏覽器上已經創建好的項目導入到本地，換句話說就是下載到本地。

Create功能

創建一個代碼庫， Name填寫你的倉庫名字。Local path寫你將要保存在本地路徑。

我們主要從這個功能開始github之旅。 我們在這裡填寫First，來創建第一個我們自己的repoeitory。

開始使用第一個代碼庫

修改第一個代碼庫中內容

我們來找到剛剛創建的代碼庫在本地的位置。就是剛剛在local path的地址路徑，當然如果你忘了，請右鍵點擊First。

選擇Open in Explorer。這樣我們就可以轉到剛剛的路徑下。 我們新建一個文本文檔。在裡面編輯。 如下

此時的github就會變成這個樣子(Changs)：

你會發現此時github會出現剛剛編輯的內容。

  1. 這個是測試文本
  2. 你好

並且前面會有藍色標識，那麼這個藍色標識是什麼用呢？

其實這個藍色標識是提示你會上改變的文本。比如我第一次只想改變 這個是測試文本並不想把你好上傳。 這時我們點擊一下你好的前面的藍色標識。

你會發現你好前面的藍色標識沒有了。

我們填寫好Summer和Description Summer就是這次改動的總結，我們也可以理解為標題*（必填），而Description可以理解為詳細概況（選填）*

我們這裡只選擇第一個修改對象，也就是這個是測試文本就行修改。summer我們填寫為第一次修改，Description我們填寫為增加了這個是測試文本的內容，之後點擊Commit to master。

切換到History目錄下 我們會發現他改變了。 這次我們把你好進行添加。

在History目錄下發生了這樣的改變。會在History目錄下形成一天時間線，來指出每一次的修改標題和內容，同時會把修改的內容用綠色標識標出。 我們打開本地的文本，刪除剛剛添加的第一行這個是測試文本。

此時你就會發現github發生了變化。 此時的紅色標識標識刪除。我們寫好Summer和Description並點擊Commit to master。 這樣我們就刪除了第一行。同時在History目錄下又多了一條時間軸。

這樣我們就完成了刪除。

上傳與同步

上傳

此時，當我們打開github網頁，就會發現此時你的修改的內容並沒有出現在這裡。這是因為你沒有進行同步，僅僅是在本地就行了修改。此時我們僅僅需要點擊右上角的publish

此時你就會本地內容已經上傳到網頁上。

同步

當你的代碼庫上傳後就會發現，原來的publish以及變為了Sync。 點擊Sync同步代碼庫！

分支的使用

創建分支

我們創建第一個分支取名為new masterh,點擊Create new branch創建第一個分支。

我們發現此時的分支已經切換到了我們剛剛創建的分支new masterch 。

我們來修改new masterch分支上的內容。 我們仍舊打開FirstDemo.txt進行編輯。輸入以下內容

創建的第一個分支。

打開github進行，填寫Summary和Description

之後我們點擊Commit to new-master在History目錄下，我們可以看到會有兩條主線，分別是master和new-master並且在new-master的分支下又一個藍色的實線空心圈和一個虛線空心圈。

實線圈表示當前的節點，空心圈表示下一次修改時的節點。

紅線標示的部分就是當前的分支

切換分支

點擊紅色劃線部分就會出現分支的列表

我們點擊master就會切換到master分支。

上傳/同步分支

這個操作和同步倉庫是一個操作，點擊Publish/Sync上傳或同步分支。

刪除分支

首先要把分支切換到你要刪除的分支下，如我們要刪除new master，將分支切換到new master

點擊右上角齒輪就會出現Delete new master 點擊Delete new master就會彈出一個對話框，詢問刪除的內容。

第一個yes ，Delete both是將本地與網頁全部刪除；

第二個Delete local only僅僅是刪除本地。

第三個是取消。

合併兩個分支

將一個分支與master分支進行合併。 我們首先把分支切換到master下，點擊Update from new-branch進行分支的合併。

此時我們查看history目錄下就會

團隊協作流程

認識Flow

GitHub Flow是一個輕量級的，基於分支的工作流程，支持團隊和部署在那裡的定期做項目。

為團隊成員寫入許可權

在我們的隊友添加一個寫的許可權，這樣我們的隊友才能很好的修改代碼。 我們打開網頁上的GitHub,點擊settings,

之後我們找到collaborators，這裡會讓我們驗證密碼，之後就有添加合作者的選項。

這樣我們就能添加我們的小夥伴了！ 這樣我們就添加了新的小夥伴，新的小夥伴有著同樣的許可權去修改和管理代碼。 此時我們就會看到我的小夥伴wevan的github主頁上就會出現關於我創建的First的各種通知。

創建分支

在我們創建一個叫add new function的分支。

創建一個分支 Create a branch 當你工作的一個項目，你會在任何給定的時間有一堆不同的功能或正在進行的想法 - 其中一些是蓄勢待發，而另一些則不是。分支的存在是為了幫助你管理這個工作流程。 When you"re working on a project, you"re going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow. 當您在項目中創建一個分支，你創造一個環境，在那裡你可以嘗試新的想法。你讓一個分支的更改不會影響主分支，讓你可以自由進行實驗，並提交更改，在你的分支將不會被合併，直到它準備好知識安全的人所正在與合作進行審查。 When you create a branch in your project, you"re creating an environment where you can try out new ideas. Changes you make on a branch don"t affect the master branch, so you"re free to experiment and commit changes, safe in the knowledge that your branch won"t be merged until it"s ready to be reviewed by someone you"re collaborating with. ProTip 分支在Git中是一個核心概念，整個GitHub的流量是基於它。這裡只有一個規則：在任何主分支總是部署。 Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There"s only one rule: anything in the master branch is always deployable. 正因為如此，這是非常重要的一個功能或修復工作時，你的新分支關老爺的創建。您的分支名應該是描述（例如，重構的身份驗證，用戶的內容緩存鍵，使視網膜-化身），以便其他人可以看到正在處理。 Because of this, it"s extremely important that your new branch is created off of master when working on a feature or a fix. Your branch name should be descriptive (e.g., refactor-authentication, user-content-cache-key, make-retina-avatars), so that others can see what is being worked on.來自GitHub Flow

添加提交

我們首先把分支切換到新的分支上add new function

修改新的版本

填寫好新的Summary和Description，提交新的版本並同步。 這樣小夥伴登陸到GitHub上就看到了就可以清楚的看到一切的修改。

添加提交 Add commits 一旦你的分支已經建立，現在是時候開始進行更改。無論何時添加，編輯或刪除一個文件，你作出承諾，並將其添加到您的分支。提交加入這一過程保持你的進步軌跡，你在一個特性分支工作。 Once your branch has been created, it"s time to start making changes. Whenever you add, edit, or delete a file, you"re making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch. 還承諾創建工作的透明歷史，其他人可以按照理解你做了什麼，以及為什麼。每次提交都有一個關聯的提交信息，這是解釋為什麼一個特定的變化作出了說明。此外，每次提交被認為是變革的一個獨立單元。這使您可以回滾的變化，如果發現錯誤，或者如果你決定在一個不同的方向前進。 Commits also create a transparent history of your work that others can follow to understand what you"ve done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction. ProTip

提交信息是重要的，特別是因為Git跟蹤更改，然後將它們顯示為承諾一旦他們推到伺服器。通過字跡清晰提交信息，你可以更容易為其他人跟著，並提供反饋。 Commit messages are important, especially since Git tracks your changes and then displays them as commits once they"re pushed to the server. By writing clear commit messages, you can make it easier for other people to follow along and provide feedback.來自GitHub Flow

打開一個pull請求

這個是整個流程中比較關鍵的一步，發布Pull Request。

點擊客戶端或者網頁上的Pull Request發布。 我們這裡點擊Pull Request

我們填寫好必要的說明性文字 點擊Send Pull Request 他既然讓我們到GitHub上看，我們就聽他的，點擊，進入。

我們發現小夥伴已經在下面留言了！

討論和審核你的代碼

你的小夥伴開始對你的代碼討論，修改，迭代。

討論和審查你的代碼 Discuss and review your code 一旦拉入請求已被打開，人或團隊審查您的變化可能有疑問或意見。也許編碼風格不匹配項目的指導方針，改變缺少單元測試，或者也許一切看起來不錯，道具都是為了。引入請求旨在鼓勵並捕獲這種類型的對話。 Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn"t match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order. Pull Requests are designed to encourage and capture this type of conversation. 您還可以繼續推送到你的分支在你提交的討論和反饋光。如果有人評論說，你忘了做某件事，或者如果在代碼中的錯誤，你可以在你的分支修復它，推高的變化。GitHub上會顯示新的提交和其他任何意見，你可能會收到統一拉請求視圖。 You can also continue to push to your branch in light of discussion and feedback about your commits. If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change. GitHub will show your new commits and any additional feedback you may receive in the unified Pull Request view.
ProTip 拉請求的意見都寫在降價，所以你可以插入圖片和表情符，使用預先格式化的文本塊，等輕質格式。 Pull Request comments are written in Markdown, so you can embed images and emoji, use pre-formatted text blocks, and other lightweight formatting.

部署

部署 Deploy 一旦你拉的請求進行了審查和部門通過你的測試，您可以部署您的更改，以驗證他們的生產。如果你的分支造成的問題，您可以通過部署現有的主投產回滾 Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.

合併

合併分支我們之前已經說過，這裡就不再贅述。

合併 Merge 現在，您的更改在生產中得到了驗證，現在是時候你的代碼合併到主分支。 Now that your changes have been verified in production, it is time to merge your code into the master branch. 合併後，引入請求保護的歷史變遷到您的代碼記錄。因為他們是搜索的，他們不讓任何人回去的時間理解為什麼以及如何決定了。 Once merged, Pull Requests preserve a record of the historical changes to your code. Because they"re searchable, they let anyone go back in time to understand why and how a decision was made.
ProTip 通過將某些關鍵字到您的拉請求的文本，你可以用代碼相關聯的問題。當你拉入請求合併，相關問題也將被關閉。例如，輸入短語關閉＃32將關閉在倉庫中發行數量32。欲了解更多信息，請查看我們的幫助文章。 By incorporating certain keywords into the text of your Pull Request, you can associate issues with code. When your Pull Request is merged, the related issues are also closed. For example, entering the phrase Closes #32 would close issue number 32 in the repository. For more information, check out our help article.

基本的一些用法就完成了。看著這個操作一遍基礎就差不多了。

這個知乎的編輯啊…………好累

----------------------------------------------------------------------------------------------------------------

在上述的幾個教程里講解了一些Github的基礎使用，現在開始講解一些使用技巧。

查找內容

在github頁面上是沒有搜索的按鈕，如何搜索呢。 在網頁上按T就會出現。 這樣我們就能很方便的查找到我們需要的代碼了。

評論小表情

常常在版本描述或者pull request時我們需要對夥伴的代碼進行一下評論與說明，光是文字有點很死板，其實github給我有emoji，如何使用呢？其實很簡單，只需要冒號就可以 ：

這樣我們就可以看到emoji表情，當然默認會顯示五個常用的，你也可以繼續敲下emoji的名字，出現更多（這裡有所有的表情）。

忽略不想上傳的文件

有些在github中的文件我們是不想上傳的，我們如何過濾掉它們呢？ 在github中對不想上傳的文件點擊右鍵。就會出現下面選項。 Ignore file忽略這個文件 Ignore all.txt files 忽略所有的以.txt結尾的文件 這樣就可以過濾掉你不想上傳的文件

搜索項目

如何高效的搜索一個你想要的庫呢？ 我們常常評判一個項目的標準有star數目，fork數目和跟新時間。 通過搜索命令

stars

stars:&>1000

表示star數目大於1000。

fork

fork:&>1000

表示fork數目大於1000。

語言搜索

java，html等等

綜合一下就是，比如你要查找一個stars大於1000的，fork大於200的java代碼。

stars:&>1000 fork:&>200 java

就是這樣。

查看項目中的語言類型

一個項目中，可能使用了多種語言，我們如何一下子就能看到一個項目使用了什麼語言？其實很簡單，Github已經為我們統計好了。

也行你注意過，但是沒有發現它有什麼用。

點擊下面的彩條

github已經為我們統計好這個項目所有的語言及其比例。

總結

碼字不易，終於寫完了，如果覺得對你有幫助，我的目的就達到了。

謝謝

如有錯誤，還望指正。

不要光收藏，點個贊

轉載請通知作者！

謝謝

--
首先你要學會git, 提供一些相關的資訊，望有幫助：

  • progit這本書是必看的
    • http://git-scm.com/book 和 http://git-scm.com/book/zh
    • 至少閱讀：第一，第二，第三，第五，共4章，即可入門。
    • 不過這個網站被牆了，提供下鏡像吧：progit-zh.epub 和 [中文].Pro Git.pdf
  • 在熟悉命令行後，也許你會需要UI，那可以選擇：
    • Downloads - msysgit - Git for Windows
    • http://code.google.com/p/tortoisegit/
    • http://www.sourcetreeapp.com/
  • 然後建議再看看 git-flow --&> 一個成功的Git分支模型
    • 介紹：A successful Git branching model
    • 翻譯：http://www.juvenxu.com/2010/11/28/a-successful-git-branching-model/
    • 工具：nvie/gitflow · GitHub
    • git-flow 備忘清單
  • 最後，你若需要本地搭建一個，那就用GITLAB: Self Hosted Git Management Application吧
  • 補充一個剛發現的互動學習git的項目： Learn Git Branching
  • 再補充一個：圖解Git
  • 再補充一個：Git Magic - 前言
  • 然後剩下github的，看官方說明吧： https://help.github.com/

下圖， 我之前對gitflow的一個翻譯：

Github的基本功能：

  • Repository：你和我一起做「知乎首頁」，「知乎首頁」就是Repository，即項目或者」未來武器T2級425mm磁軌炮「之類，怎麼叫隨你，你只需知道Repository是個放項目的地方就行。有時候會出現Repositories，是多個Repository的意思。
  • Fork：我們把製作「知乎首頁「的工作分開，你負責美工，我負責前端開發，但我們還需要數據伺服器高手。你找來了一位php大牛，這位大牛很快搞定了伺服器端，閑來無事，就看了看我的前端代碼，一看，「我靠，這怎麼一點也不語義化呢？全是尼瑪的清一色的&啊，將來做交互js還搞不搞dom了……」於是這大牛在Repository中找到了我寫的「zhi.html」，Fork了一份，也就是授權拷貝。
  • Branch：Fork之後，在大牛的Github上出現了一個同樣叫做「知乎首頁」的Repository，但是這個Repository是複製品，只歸他，這就是他的Branch，也就是分支。
  • Pull Request：大牛做完了一份全新的高端zhi.html，點了Pull Request，也就是推送請求。我接受了，看了一眼，頓時驚訝爆表，「中國足球——高，實在是高！」
  • 現在你懂了，Github的結構是Repository-Branch-(獲取/推送)文件。你又發現Github可以比較兩個文件的異同，新增的部分用綠色標記，刪除的部分用紅色標記。Pull Request還可以控制，甚至可以合併Branch，這就是團隊合作利器啊，真乃高大上也，手癢了吧？心動了吧？
  1. 註冊Github並登錄。
  2. 下載客戶端並登錄，客戶端負責你硬碟上的數據與Github伺服器數據的交互，然後設置存儲目錄。為了表現你的才華，你決定將此目錄命名為「諸神之爹」。
  3. 既然有這麼多的國外開源項目，我們國內哪有不自主的道理。必須要實踐一下這個頂好贊的Fork功能。現在你來到了Fadeoc/frontend · GitHub，你看到了這是用戶Fadeoc的一個叫做「frontend」的Repository，你笑了，這傢伙學習前端知識不過十天，代碼一片渣，竟然有的代碼里只寫了「土豆」和「二狗子」幾個漢字。你點了一下右上角的Fork，然後clone in desktop，保存到「諸神之爹」，哇！文件已經在你電腦里了，完全免費耶！+10086！
  4. 一個小時後，你對Fadeoc的渣代碼頗有心得，決定幫他改良，不然他這項目就完了。你改好之後，Pull Request，這丫的竟然說你的代碼太渣，不吸收。賤人！老子自己做，搶你市場份額！
  5. 你點了右上角自己頭像後面的+號，選擇了第一個New repository，即新建repository，並且起了個名字，叫做「完爆Fadeoc」，然後點擊綠色按鈕set up in desktop，彈出保存框，選擇「諸神之爹」。於是「諸神之爹」下出現了一個「完爆Fadeoc」的文件夾。
  6. 你自己寫了一份「神爹首頁.html」，把它放在了「完爆Fadeoc」文件夾下。
  7. 你打開了客戶端，看到客戶端界面中master Branch（主人分支，這名字太雲端了）出現了一個Uncommitted changes，即未提交的變動，也就是你剛寫的「神爹首頁.html」。你點開show按鈕，在summary（摘要）的部分添上「滾你丫的Fadeoc」，在Description（細節描述）的位置是沒必要寫的，但你還是決定添上「爆你菊花」四個大字。然後選擇「Commit to 你的用戶名」。
  8. 為了把這個提交上傳到Github上讓賤人Fadeoc看到，你點擊了客戶端右上角的後面顯示了一個「+1」的Sync，即同步，過了幾秒，Sync前的兩個曲線箭頭停止了轉動，同步成功了，「+1」消失，表示一個文件成功上傳。
  9. 你來到Github，刷新自己的個人頁，「完爆Fadeoc」這個Repository出現在頁面上，點開它，在裡面你看到了」神爹首頁.html」。
  10. 為了讓這個項目的初始目的更加淺顯易懂，你決定添加一個Readme.txt，雖然從前下載的N多軟體的文件夾里總是有一個Readme.txt，你一個都沒打開過。但在圈裡混，就得混的人模狗樣的，於是你在「完爆Fadeoc」下新建了一個Readme.txt，裡面寫上，「Fadeoc，沒錯，說的就是你，看我口型，你個賤人！」
  11. 同樣使用客戶端commit，然後sync，過了幾秒，刷新github，你看到又多出了一個readme.txt。而且在下面又多出一個文字顯示框，裡面顯示的就是readme.txt裡面的內容「Fadeoc，沒錯，說的就是你，看我口型，你個賤人！」，避免了Fadeoc這個賤人不想打開readme.txt也就看不到你親切問候的尷尬局面。Github真是貼心吶。
  12. 你複製了這個Repository的地址，Email給了Fadeoc。
  13. Fadeoc不是那麼容易被打敗的，於是他Fork了你的Repository，修改了readme.txt，然後pull request，你看到fadeoc新生成的branch下的readme.txt被改成了「你才是賤人」。你拒絕了合併請求。
  14. Fadeoc再次pull request，readme.txt改成了「敢不做惡嗎？」
  15. 你有點煩了，這他媽的怎麼才能不讓他pull request，將來大項目N多陌生人菜鳥pull request煩不煩，就不能不開源，轉私有嗎？你終於找到了Github的升級服務，你笑了，將這個Repository從Public轉成了Private。Fadeoc肯定會繼續pull request，得不到你回應的他只會漸漸被複仇的怒火燒盡理智，可是，誰在乎呢？

Github還有更多細節功能，在使用過程中，你會慢慢發現，慢慢學會。但是不管如何，現在你會使用Github的基本功能了。

放（打）一（廣）個（告）比較有意思的《GitHub - phodal/github-roam: GitHub 漫遊指南》電子書，當然也是放在GitHub上的。

漫遊在第547天里：phodal (Fengda Huang) · GitHub

  • 前言
    • 我與GitHub的故事
      • GitHub與收穫
      • GitHub與成長
    • 為什麼你應該深入GitHub
      • 方便工作
      • 獲得一份工作
      • 擴大交際
  • Git基本知識與GitHub使用
    • Git
      • Git初入
    • GitHub
      • 版本管理與軟體部署
      • GitHub與Git
      • 在GitHub創建項目
    • GitHub流行項目分析
    • Pull Request
      • 我的第一個PR
      • CLA
  • 構建GitHub項目
    • 如何用好GitHub
      • 敏捷軟體開發
      • 測試
      • CI
      • 代碼質量
    • 模塊分離與測試
      • 代碼模塊化
      • 自動化測試
      • Jshint
      • Mocha
      • 測試示例
    • 代碼質量與重構
      • Code Climate
      • 代碼的壞味道
  • 創建項目文檔
    • README
    • 在線文檔
    • 可用示例
  • 測試
    • TDD
      • 一次測試驅動開發
      • 說說TDD
      • TDD思考
    • 功能測試
      • 輕量級網站測試TWill
      • Twill 登陸測試
      • Twill 測試腳本
    • Fake Server
  • 重構
    • 為什麼重構?
    • 重構uMarkdown
      • 代碼說明
    • Interllij Idea重構
      • Rename
      • Extract Method
      • Inline Method
      • Pull Members Up
      • 重構之以查詢取代臨時變數
  • 如何在GitHub「尋找靈感(fork)」
    • GitHub 漫遊指南 -Lettuce構建過程
      • 需求
      • 計劃
      • 實現第一個需求
      • 實現第二個需求
  • GitHub用戶分析
    • 生成圖表
      • 數據解析
      • Matplotlib
    • 每周分析
      • python github 每周情況分析
      • Python 數據分析
      • Python Matplotlib圖表
    • 存儲到資料庫中
      • SQLite3
      • 數據導入
      • Redis
    • 鄰近演算法與相似用戶
  • GitHub連擊
    • 100天
      • 40天的提升
      • 100天的挑戰
      • 140天的希冀
    • 200天的Showcase
      • 一些項目簡述
      • google map solr polygon 搜索
      • 技能樹
    • 365天
      • 編程的基礎能力
      • 技術與框架設計
      • 領域與練習
      • 其他

順便放上我的微信公眾號的二維碼。

http://weixin.qq.com/r/mnVYQHrEVicprT4j9yCI (二維碼自動識別)

作為全球最大的程序猿（交友）網站，GitHub 本身以及圍繞 GitHub 的各種插件使得其項目管理能力遠比你所能想像的厲害得多。

  • 收集：需求無時無刻，無處不在，anywhere anytime
  • 整理：as BA，即分析，Elaboration Estimation IPM =&> 確定 MVP Efforts
  • 執行：as Dev QA，Developing Testing Review/Sign-Off
  • 回顧：Retrospection，Introspection，持續反思，持續進步…

通過 GitHub Issues 收集需求

首先你可以給自己建一個 GitHub 倉庫作為主頁，比如我的 JimmyLv/jimmylv.github.io: Agile Learning based on GitHub issues ，最開始就是從個人博客的主倉庫發展而來。那麼，如何快速收納自己的想法呢？以解決問題為導向，就是有什麼需求就直接給自己的 repo 建一個 issue 作為 Story Card，了卻這個需求的最終形態就是 close 掉這個 Issue，比如我要寫這篇文章就始於這個 issue：基於 GitHub 的敏捷學習方法總結 · Issue #36。

GitHub issues 的進階用法

與此同時，新建 issue 還有更高級的用法，也就是通過 ISSUE_TEMPLATE 這樣一個模板來新建某個 issue，從而更快地定位問題所在和解析自己的想法，最主要的是能夠輸出更具體的 TODOs，即下一步行動的具體內容，這個還會在後面詳細解釋。

issue 和 issue 之間是可以通過 # 相互連接，甚至可以跨倉庫，被 reference 的 issue 也會出現在另外一邊的 issue 裡面；

  • 而通過 #! 符號是可以在 comments 裡面直接新建一個 issue ，這在思維爆炸的時候來得特別爽快；
  • 你還可以隨意艾特你的小夥伴們，互相監督、互相學習或者給出 Constructive Feedback 之類的，https://s.w.org/images/core/emoji/2.2.1/svg/1f602.svg；
  • 更甚至於，若是在 Intellij 裡面關聯了 GitHub，就可以在 git commit 信息裡面直接看到你所要關聯的 issues 列表了。

這種方式彷彿學習中的大腦，神經網路被連通了的感覺。

移動端的解決方案

而在移動端則可以通過 GitDo 這個 App 來輕鬆新建和管理自己的 Issues，沒錯，就是有人把 GitHub issues 做成了一個 Todos 類 App，還做得很漂亮功能很完善。只是不知為何這軟體最近被下架了，傷感，我就又重新把滴答清單（TickTick）作為自己的萬能收集箱了，之後再把比較重要的、需要進一步追蹤的事項添加到 GitHub issues 裡面來。

整理你的 GitHub Issues

大膽地把 issues 作為你的個人需求列表吧，需要解決的問題可以大到做一個開源項目，或者小到讀一本書、寫一篇文章。對於比較大的需求，你還可以將其轉化為 Epic 然後把拆分過後的小 issues 們加入到這個列表裡面來。

而 GitHub (with ZenHub) 強大的 issues 管理能力絕對會讓你的迭代工作變得井井有條，使用 GitHub 新出的 Projects 特性或者使用 ZenHub 的 Boards 就可以讓你瞬間擁有日常敏捷工作的感覺了吧！

計劃與執行具體任務

制定迭代計劃

首先，讓我們新建一個 Milestone 來制定計劃，也就是決定在一個 Iteration 裡面你需要完成哪些 issues。在這裡我所制定的階段性計劃周期為一個月，當然你也可以勤快一點，以2周作為一個 Iteration，享受一下自己的計劃要完成不了、這個 Milestone 就要廢了，沒法向「時間」這個一生的朋友交付所有需求的快感吧 ：）

當然咯，一般我會在月初做計劃的時候給自己準備專門的時間來做 Elaboration，把 Backlog 裡面的卡拖到 Rethink/Plan 這一列，經過分析和詳細輸出 TODOs 以及所對應的估點 points 之後便可以將其拖到 Ready For Todo 了，一般我給自己估的點數就是完成這件事情所需要的時間，一小時即對應一個 point。

這樣你就可以愉快的選擇 Filter Issues by Milestone 專註於當前 Iteration，專註於 In Progress 這一列所要做的事情，並且垂涎於 Ready For Todo 裡面將要做的事情，每次做完還可以放到 Review/SignOff，在裡面寫寫對這件事情的總結和感想什麼的，每次挪卡都充滿了敏捷的儀式感（認真臉）。

進度的把控

GitHub 在 issues 裡面直接集成了 Markdown 的 TODO 語法，甚至於可以在渲染過後直接拖動某個 item 進行排序，而且可以在前面的勾選項中直接打勾 https://s.w.org/images/core/emoji/2.2.1/svg/2611.svg 標記為完成。不僅如此，完成之後這個 issue 還能直接顯示完成進度；前面所提到的 Epic 也能直接顯示子 issues 的完成情況即 closed 比例，兩者結合起來簡直不能再美好。

比如說拿來作為讀書列表的記錄就很不錯，每本書作為一個 issue，還可以把章節劃分為具體的 TODOs，結合估點追蹤自己看書的進度和速度，順便在 comments 底下做個筆記也不錯啊！

專註當下

ZenHub 還提供了一個基於 GitHub Issues 的 To do List，你可以只關注 Today 這一個列表，專心於當前要完成的任務。而且更有趣的是這個 list 可以加入 GitHub 的任何 issues，也就是說它是全局的，所以你可以加入很多在 GitHub 上通過 issues 寫的 blog，比如徐飛的這篇文章流動的數據——使用 RxJS 構造複雜單頁應用的數據邏輯 · Issue #38 · xufei/blog，被我加入到了 Reading列表當中。

與此同時我還會使用 Toggl 來記錄每個 issue 具體實施的時間，以便於在時間花費上能夠獲得及時的反饋。這樣做會讓你真切地感受到時間的流逝，而在回顧記錄的時候也能夠進行總結分析，從而在下一次的計劃當中更精確地預估時間（點數）。比方說這篇文章我估了 5 個點現在已經寫了 4.5 hours 了，不過這是另外一個大話題，可以參考 記錄時間這件小事兒 這個 issue。

迭代回顧與總結分析

ZenHub 也提供了 Burndown 和 Velocity tracking 圖，可以得出這個迭代總體的完成情況，看看跟預期有何不同；也可以跟其他迭代進行對比，看看有何不同的地方，然後進行下一步的具體分析。

還可以根據 GitHub 和 Toggl 裡面的數據進行匯總和分析，下面這個表格就是我在 11 月這個迭代完成後一部分 issues 的具體 Estimation Points 和 Time Efforts，再結合 issues 裡面所記錄下的各種筆記和 references，來得到一個比較直觀的總結和復盤。

Number DescriptionEstimation PointsTime Efforts#85 記錄時間這件小事兒304:26:18#96 如何對時間進行分類？803:00:09#102 建立個人 Wiki 系統202:53:56#101 技術雷達宣講：enzyme 測試框架506:11:19#90 Working time improvement133:27 min#97 如何使用 XX 的標籤系統？125:21 min

其他輔助工具

  • 看板：as Jira/Trello，可視化當前進度 =&> GitHub Issues group by @Projects / 日曆 in @滴答清單；如果你不想用 ZenHub ，可以試試 Gitlo ，可以在 GitHub issues 和 Trello 之間進行雙向同步。
  • 晨間日記/每日回顧：as Stand-Up，只用關注 Timeline/Done/Todo/Blocker 以及當天的心情/天氣等等，使用 @格志日記的一個特點就是可以通過問答的方式對一天進行回顧。
  • 時間記錄：@時間塊的優點在於記錄起來非常簡單、快捷，是用戶評論中最省時間的時間記錄工具，沒有之一，推薦新手試試。但由於個人需要更加詳細的記錄細節和報告分析，以及多平台（包括 Chrome Extension）的支持，從而選擇了 @Toggl。
  • 白雜訊：作為一款時間記錄工具，@Toggl 本身就支持 Pomodoro 的 25 分鐘提示。而作為專註力輔助的白雜訊軟體我在手機上用的 @潮汐，電腦上則選擇了 @Noizio。

後話

也許你很喜歡這個解決方案但又不太想公開自己的 issues 列表，那可以試試 GitHub 的 private repo（需要付費），免費的可以試試 GitLab，支持從 GitHub 一鍵導入，並且已經原生支持了 pipeline 和看板功能。當然，不限於工具或軟體，這一套方法論其實是可以運用在任何地方的，甚至於我們可以來做一個結合敏捷方法論的個人學習管理軟體也不錯。

但是於我而言，選擇在 GitHub 這樣一個公開環境下記錄學習的最大一個動機就在於「開源」，很喜歡一句話，大意是「在這個互聯網時代，能限制住學習的只有你的求知慾」。

http://insights.thoughtworkers.org/wp-content/uploads/2017/05/14-knowledge-1-1024x683.jpg

當你從互聯網這個廣闊的知識海洋當中汲取知識時，也應當有所輸出，即反哺到整個互聯網當中去。我會經常寫博客/筆記來總結、分享自己的所學，但是一篇文章誕生的背後往往還有很多其他知識和經驗的相互交融與沉澱。Issues · JimmyLv/jimmylv.github.io 這個列表裡面的某個 issues 最終能否演變成一篇文章我不知道，但是基於 GitHub 開放式的學習歷程都會被這些 issues 如實地記錄著，任何一個想法都能追本溯源被找出最開始的緣由。

相比於軟體開發這件小事兒，健康快樂地成長顯然要重要得多。—— 立青

文／ ThoughtWorks@呂立青 全文請戳：基於GitHub的敏捷學習方法之道與術 - ThoughtWorks洞見

可以按照《Github 快速上手實戰教程》操作一遍，學習下如何使用Github去管理使用的代碼、配置、資源等文件，怎樣去添加、同步和下拉在遠程倉庫中的文件。每一步操作都有演示。

如果想系統學習git 的操作，可以參考《Git 實戰教程》

熟悉後可以在Github上做個簡歷練練手，程序員必備：《在Github Pages上部署自己的簡歷》

以下是Github快速上手教程的節選內容。

1.1 Github 的使用

講解如何創建 Github 賬戶和如何創建遠程倉庫

1.1.1 創建賬號

到 Github 註冊 頁面中註冊，填寫用戶名、郵箱和密碼

選擇免費服務

步驟三可以根據自身喜好勾選或者直接跳過

1.1.2 創建遠程倉庫

創建完賬號後，可以開始創建倉庫

但是這裡我們還沒有驗證郵箱，所以點擊開始一個項目會跳出一個頁面讓我們驗證郵箱

到郵箱中點擊驗證鏈接，驗證完畢後會跳到之前的 Guide 頁面，而且頂部會有一個郵箱驗證完畢的提示

再次點擊開始一個項目，成功進入創建項目頁面，填寫項目名稱和描述，勾選 Public（Private是收費選項） 選項和自動初始化 README.md 勾選框

點擊創建，至此 Github 賬號的創建和遠程倉庫創建完畢

1.2 SSH 公私鑰的使用

講解如何使用 ssh-keygen 生成公私鑰

1.2.1 創建密鑰

首先在終端敲入，如果一路一直按回車下去，會把密鑰文件放置再默認路徑，也就是 ~/.ssh/ 路徑下，並且會創建一套空密碼驗證的密鑰文件，反之則每一次匹對公私鑰都需要再手動輸入一次密碼，所以這裡為了方便使用，建議一路回車下去就行

$ ssh-keygen

輸入密鑰文件保存路徑，建議默認路徑，按回車跳過

要求輸入密碼，建議回車使用空密碼方便以後的每次連接

到選擇存放密鑰文件的路徑下查看，我這裡使用的使默認路徑，所以使 ~/.ssh/ 路徑下，可以看到生成了兩個密鑰文件，後綴為 .pub 的就是公鑰文件，另一個沒有後綴的就是私鑰文件，可以看到密鑰文件創建完畢

1.2.2 關聯公鑰到 Github 賬號下

首先複製公鑰文件中的內容，也就是 ssh-rsa 開頭到 用戶名@主機名 這段字元串

然後回到 Github, 點擊右上角頭像的下拉按鈕，選擇 Settings

然後在 Settings 頁面中選擇左邊菜單里的 SSH and GPG keys，然後點擊右上角的 New SSH key 按鈕，填寫 Title 和 Key，然後點擊 Add SSH key 按鈕提交

通過返回的頁面可以看到公鑰與 Github 已經關聯完畢

1.3 安裝配置 Git 工具

介紹如何安裝與簡單的配置 Git 工具

1.3.1 安裝

首先在終端下面敲入 git --version， 如果正確回顯版本號，則說明已經安裝好，如果沒有則在終端敲入下面這條命令進行安裝

$ sudo apt-get install git -y

1.3.2 配置用戶名與郵箱

配置用戶名

### 如果想設置為全局生效，添加 --global 參數
$ git config --global user.name "你的用戶名"
$ git config --global user.email "你的郵箱"

創建好github賬號後，我們就可以開始練習github的基本使用了，下面內容都可以在實驗中直接查看和練習：《Github 快速上手實戰教程》

克隆遠程倉庫到本地

添加實驗文件到索引庫

提交倉庫的改動

推送改動到遠程倉庫中

在新的環境中同步之前的文件

在本地個人計算機中同步在線環境中的進度

推薦廖雪峰的Git教程，通俗易懂。
跟著教程下來，add，commit，branch等各種命令有較深刻的了解。
Git教程 - 廖雪峰的官方網站

首先你要學會使用git，推薦pro git這本書。
關於github的使用，看這裡http://www.worldhello.net/gotgithub/，非常好的介紹

為什麼沒人說Command Line???

新手都覺得command line太難，其實不然，就那麼幾個需要用的命令，多用幾次就記熟了。記熟了不但操作極為方便，也是裝X利器啊！！


跑題了。先說GitHub

請大家假設以下的情景，現在有一個項目，要有兩個人來完成，小明和小紅。

小明和小紅一人一台電腦，分別在兩個屋子裡工作。

首先在GitHub上有一個原檔，小明小紅分別下載到自己的電腦里開始工作。

假設原文檔如下

str = "Hello Zhihu!"

for letter in str:
print (letter)

這時候小明說，好，我來接著寫

name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)

for letter in str:
print (letter)

小紅拿到文件之後也說，好，我來接著寫。

str = "Hello Zhihu!"

for letter in str:
print (letter)

str1="LiMaBianWangHong"

這個時候小明和小紅是互相不知道對方在幹什麼的。


但是兩個人必須同時完成這個coding，這個時候該怎麼辦呢？

沒錯，在GitHub上同步兩人的文件。

小明先從GitHub上下載。小明一看沒變化（此時小紅還沒上傳），於是把自己的改變傳上去。

此時原文檔變成了

name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)

for letter in str:
print (letter)

這時小紅開始同步，她的文件變成了這個樣子：

name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)

for letter in str:
print (letter)

str1="LiMaBianWangHong"

小紅確認了code無誤之後又把自己的code同步到Github上

這時小明再同步，他就會看到

name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)

for letter in str:
print (letter)

str1="LiMaBianWangHong"

這個時候小明看著str1不順眼打算，改一下

name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)

for letter in str:
print (letter)

str1="ChouNv"

與此同時小紅也覺得str1有些彆扭，她也改

name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)

for letter in str:
print (letter)

str1="XiaoHongShiNvShen"

這時小明先上傳了上去，小紅一同步一看

一頭霧水。這時什麼呢，因為兩個人同時修改同一行，所以出現了merge confilict

name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)

for letter in str:
print (letter)
&<&<&<&<&<&<&<&<&

這個時候怎麼辦呢，就要手動修改。把提示的line全都刪掉即可。

name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)

for letter in str:
print (letter)

str1="XiaoHongShiNvShen"

print("xiao ming shi sb"）

講到這裡大家應該就對github有一個大致的印象了。基本就是個同步工作進程的工具。

那麼實現同步都需要哪些命令行呢？其實很簡單。我保證你一分鐘就能記住。


小明或者小紅得先看看github上有沒有其他人的更新，所以他要先輸入

&>&>&> git status

這個很好理解吧，就是查看狀態。

如果這時候先是說有修改過的文件，那你就要下載下來對不對啊。

&>&>&> git pull

是不是很簡單，往下拉

你拉下來之後，核對了，無誤，要把自己的成果發布上去，怎麼弄呢？

你想像兩座山之間，要傳遞食物，中間有個小滑索的車，你是不是先把食物放進小車裡，之後把小車推到對面的山去呢？

這裡也是一樣的，你要先

&>&>&> git add

先添加，add後可以跟-a 就是添加all 添加全部的意思，或者添加一個具體的文件，比如

&>&>&> git add xiaoming.txt

現在食物放進車裡了，下一步呢？
對面的山裡人可能不知道你這吃的是什麼，你是不是得寫個條子留個言告訴別人是什麼食物啊？

&>&>&> git commit -m "這是漢堡包"

commit不難理解吧， -m就是message的意思。是什麼message呢？ 「這是漢堡包」
一般這裡寫你對文件做出了什麼修改 比如

&>&>&> git commit -m "new feature: xiao hong bian bai fu mei"


至此你應經做完全部準備工作，就差推出去了！


&>&>&> git push origin master

push很好理解吧，origin master 代表你的許可權。多用幾次就熟悉了！


以後不用開網頁，用terminal上傳文件到github，逼格高高的！

祝好！

你們如果以為我只會秀恩愛那就錯了，應讀者要求，最近在寫一個針對小白的從0開始學習GitHub的系列，無門檻，包教包會，現在這本電子書已經寫完了，名字叫做「從 0 開始學習 GitHub」，現在免費送給需要的人，公眾號 AndroidDeveloper 回復關鍵字「GitHub」獲取。


++++++++++++++++++++++++++++++++++++++++++++++++++++

我對GitHub可是真愛粉，媳婦也是寫程序的，也知道GitHub，今天我發給媳婦一個鏈接，說你看我GitHub粉絲都漲到多少啦，媳婦一臉不屑的打開我的GitHub，然後就感動的哭了。。。

是的，正確使用GitHub的方式是用來----秀恩愛！

想給剛開始使用Git的小白一個最簡易的小教程。

任務：用Visual Studio 編寫一個加減的計算器。

第一步：打開VS, 一般情況下，新建一個空白的solution, 並且把『新建git repository』 check.

新建基本的加法和減法的project.

然後打開電腦的document. 發現local repository 有了這個新的project, 並複製GitCalculator的地址。

第二步：打開Sourcetree. 管理正在進行的project.

點擊 Add a repository. 把GitCalculator的地址黏貼上。這樣就可以方便管理了。

畫面如下：

你所做的任何小的操作，或者你認為重要的要Commit, 這一步的意義在於將你在VS上的操作保存到local repository.

Master相當於管理者，你可以想像成這個加減計算器的最終管理者，只接收最終版本。這時候點擊Git flow, 就相當於他把任務分配出去，這個操作就是新建了一個Branch-develop. 所有的操作都會在develop上。

第三步：建立develop

個人認為，個人操作的話，最好的方式是從develop裡面建立新的branch, 然後進行操作是最好的方式. 也就是從develop建立另一個branch-feature.

第四步: 你開始編程了，編啊編，你覺得這個加法程序寫好了，這個時候你需要幹什麼？對，要Commit!

加法的程序寫好啦，也就是說不需要這個加法的feature了。把它丟掉，然後把這個寫好的程序merge到develop 裡面。

第五步：Merge feature 到develop 裡面去！

你將看到這個寫好的程序都匯入了develop 裡面。假如你接下來想寫減法的程序了，就直接在新建一個新的branch-feature, 然後 commit, merge. 以上的操作就好啦~

以上的步驟呢，是一個人寫程序，管理程序的步驟。如果多個人共同寫一個大程序，就需要進行local repository和origin repository的pull 和push 的操作啦。

雖然是很小的簡單操作，還是希望對剛使用sourcetree 的同學有所幫助~

讓老媛先「用寫小黃文來解釋GIT」可好？

  • 胸懷大志的你，立志要寫小黃文
    於是你在本機奮筆疾書了三個月，然後電腦硬碟被某白色液體弄壞了...
    卒
  • 於是你想：哎，要是我能把小黃文存到遠程伺服器上就好了，這樣就算我本地掛了，我再從遠程拷一份，不就666了？
  • 說干就干，
    從此你每次寫小黃書時，
    都要在遠程伺服器里創建一個專門的文件夾，
    來存放這本小黃書的章節，以及相關資料
    這就叫做 create remote repository
  • 而在你本地的那個，
    和遠程伺服器一毛一樣的那個,
    每個小黃書一個的文件夾
    就叫做 local repository
  • 但是每次用郵件或者FTP（文件傳輸協議）來同步 remote 和 local 的 repository，簡直麻煩
    於是你搞了一個叫git的程序，幫你管理 repository，
    用 git init 來 create repository,
    用git clone 將 remote repository clone到 local,
    用git push 將local repository clone到 remote
  • 然而，在一個美麗的夜晚
    當你正要 push 到遠程時，
    電腦突然斷電了，
    卒
  • 這可把你氣壞了
    原以為有了遠程伺服器，就可以美滋滋了
    居然會在push到遠程之前就搞幺蛾子
    於是你清楚的意識到
    git需要有一個類似ctrl+s的東西
    能讓大家實時保存修改
    嘔吼，這就是git里的git add
  • 這自從你有了一個小黃書的遠程伺服器，就再也沒因為白色液體而返工。
    於是乎，你的小黃書寫的越來越順手，很多影視都借鑒與你，所以你賺了個滿盆盈利
    這是，你琢磨起了組建團隊，
    畢竟以你的經驗，可以監管和指導一群新人來寫小黃文
    但新人之所以稱為新人，就是因為他們每個人只擅長一部分，比如：
    A只擅長描寫日常撩撥，B只擅長寫床笫之歡，C只擅長寫渲染氣氛
  • 你一想：
    如果讓他們配合著寫，每個人只寫自己拿手的
    那不僅質量高，而且並行寫的速度快
    客戶保證滿意
  • 說干就干，
    你定好了故事的發展大綱，
    然後給ABC各分了一塊他們所擅長的部分，讓他們去具體寫
    兩個月後，他們終於寫完了，
    雖然拖remote repository的福，到是沒有丟失過數據
    但當你要去把ABC寫的內容合併時，
    呵呵呵，
    A的第一段應該在B的第二段後面，C的第一段應該放在A的第一段前面，A的第二段又要跟在C的第二段後面，C的第二段應該放在B的跌三段後面%￥%￥#……
  • 絕望吧，
    你必須把ABC寫的東西一行行的看過去
    才能理清楚他們寫的東西之間的邏輯
    才能將他們寫的東西正確的拼湊在一起
  • 摔，這樣拼湊簡直不是人能幹的事
    於是你想了個辦法：
    你把最開始定的那個大綱啊，作為master
    讓ABC每天都把他們寫的東西，都加到mater上
    這就叫做創建分支
    於是有了git branch &
  • 啊，這個git branch不管在remote 還是 local都可以進行
    反正相互都會同步的嘛
  • 現在你的團隊決定再寫一本《我的香艷小秘書》
    於是乎，你在遠程倉庫里，
    先創建了一個名叫《我的香艷小秘書》的 remote repository，
    現在這個remote repository只有一個默認的 master 的分支，

  • 然後git clone到你在本地，把大綱寫到master分支後

  • git push 到 remote repository的 mater 分支，

  • 你又用 git，基於 master 分支，給ABC分別創建了一個分支，

  • 然後 ABC 每個人，在本地用 git clone 了 remote repository，
    啊哈，ABC 就都在本地都有了一個名叫《我的香艷小秘書》，
    但處於不同分支的 local repository

  • 誒呀呀，
    C第一個完成了第一天的工作，
    於是C開開心心的把push到自己在remote repository里的分支
    正準備收工，溜的時候，想起你要求他們：
    每天下班時要把自己的分支和master分支合併
    於是C在remote repository里，將自己的分支merge到了master分支
  • 終於A也終於寫完了，A也push到remote repository
    但當A要merge到master分支時，
    master不知道要把A新加的東西，是放到C新加的東西的前面，還是後面，還是裡面...
    於是不得不拒絕A 的merge請求，
  • orz，A就只好先在自己本地的分支裏手動合併，
    即：把C增加的東西放到合適的位置上，
    再git push 在A的remote 分支，
    之後再merge 到 master分支，
    這就叫做解決衝突
  • 但第二天早上你一看master，有幾句的是什麼狗屎哦，
    於是你把A叫過來一頓臭罵，
    然而這幾句是C寫的...
    於是你決定，在git push前時候要加上一些信息，
    能讓你知道是誰寫了啥
    於是乎，git commit出現了
  • 並且！！！
    不能隨意的merge到master上
    萬一merge了一堆狗屎咋辦！！！
    必須提一個pull request請求給你
    等你審核過後
    才能進行merge到master上

/************************************************************************************************/

  • 我。。。我明天再寫為啥要有回退，以及stash
    我。。。我明早上班要起不來了
    日常絕望

/************************************************************************************************/

誒呀，現在你終於可以每天喝喝茶
等有pull request請求的時候，再審核審核
通過 OR 寫修改建議+駁回
然後躺著數錢啦~~~

/************************************************************************************************/

  • 現在你已經會用git來輔助團隊寫小黃文了吧！！！
    很好，把小黃文換成java/python/*()(^%$*^%%$^#*工程
    恭喜你，你就會用git來管理工程了！！！
  • 至於，github是啥？
    你是豬皮嘛？？？
    github不就是那個遠程伺服器嘛
    雖然他是公開的，但是你花錢可以弄個私有的啊
  • github咋用？
    你是騷豬皮嘛？？？
    無非就是建個remote repository，再建個分支
    然後在本地clone一個一毛一樣的
    然後寫你的小黃書唄
  • gitlab啊，gogs是啥？
    你是真騷豬皮嘛？？？
    就是你在遠程伺服器上，給自己專門搭一個github玩，
    這樣就可以不用給github交錢，還能有自己私有的遠程倉庫啦
    再說了，
    用github的公司是不是有點low...
  • SSH是啥？
    就是配置好後
    你在本地連接remote repository時，不再需要用用戶名密碼驗證身份了
之前有在V2EX上看到有人分享過一個簡易教程，圖文並茂的，猛擊這個網址 git - the simple guide 。非常詳細，除了用很Q的圖形教程給出操作流程步驟外還提供了不少有用的外聯資源。
 如果作為使用者的話，大多數情況下是git別人的代碼進行查看，或是git做好的源代碼configure和install。
如果是作為開發人員，不得不說免費用戶上傳的代碼全部開源，所有人都能夠查看，所以別不好意思。

9.30更新...視頻沒看完...太啰嗦...我選擇花一天時間看完廖雪峰

…………………………………………………………………………………………
Udacity ——→網頁鏈接

Google推薦的Udcity平台，你值得擁有。如何使用git和github這門課，github有34節課，加上git一共114節課，幾位導師都是在google工作的....視頻是在youtube上，網頁上有中文字幕。ios和android也可以下載APP看（不用fq！！！），不過移動版本沒有中文字幕。是不是最詳細的github使用教程了！！！

萌新不求關注，點個贊讓更多的人看到就可以了。

首先了解什麼是Git，為什麼，如何使用Git
然後GitHub的使用就順理成章了。
關於Git和GitHub的學習，推薦 Udacity 的 UD775 課程，對於初學者是非常好的入門教材，這門課程大概需要3個小時時間，之後相信你就可以比較熟練地使用Git和GitHub了。
Udacity的課程設計以Self Paced 為主，很適合想突擊學習一方面知識的人。
課程連接： Advance Your Career Through Project-Based Online Classes

Github

陽志平：」正是Github，讓社會化編程成為現實。本文嘗試談談GitHub的文化、技巧與影響。」 在陽志平：如何高效利用GitHub文中介 紹了Github的方方面面，包括一些很有意思的創意，如用Github做PPT，發布婚宴的邀請函等， 可以讓人快速擁抱Github，十分不錯。

  • How to build a Github，Github一名早期員工介紹Github的歷史，5年108名員工無人離職。
  • 陽志平：如何高效利用GitHub，信息量很大，值得深入學習和實踐。
  • Got Github，蔣鑫，介紹Github的開源書籍，你真的了解Github嗎，如果不了解，可以認真看看此書。

Git

  • Pro Git，Git深入淺出教程，中文版。不過git-scm被blocked了。這是一本開源的書籍，源代碼見Pro Git on Github。
  • Git Internals PDF，來自Peepcode的開源書籍，源代碼已經放在Github。
  • Git Reference，Git參考手冊。
  • Linus講解git，Google大會演講，Linus介紹他創造git的原因，對比了git和svn。
GotGitHub — GotGitHub

一個簡潔而優美的教材：

git - the simple guide

我看著它解決了一個重要的問題。

如何高效利用GitHub ← 陽志平的個人網站::技術

推薦閱讀：

※學習編程需要安裝哪些軟體？
※C 與 C++ 誰的效率高，為什麼？
※對使用 C++ 異常處理應具有怎樣的態度？

TAG:編程 | Git | Java | GitHub | C++ |