如果你只是想了解 github 的使用，請跳到 Github 簡介一節。

版本控制簡介

至于什么是版本控制？作為程序員大軍之一，想必大家有這樣的經歷吧。開始一個項目的時候，腦子一熱，把程序一下子寫了七七八八了，然后慢慢地到了瓶頸了，要實現新的功能，要改變某些結構。這個過程肯定是有很大風險的，說不定改變的時間要很長。但是客戶又在催著要代碼，那就為當前的版本起一個版本號吧，然后復制一份來重新改寫部分，如果寫好了，就交新的代碼，改不好就又回到原來的版本。至少還可以交差。版本控制工具的原理也是這樣，只是這個工具把代碼都壓縮存儲了，省得自己手工復制代碼然后存儲。

然后我們來看看另一個場景。一個團隊的人希望合作開發一個軟件，為了讓所有人都看到最新的改動，他們把代碼放到一個 ftp 上，然后每個人做完自己的工作后，上傳到 ftp 然后替換相關的文件。但是，我們知道，軟件的開發很難做到完全不耦合，或者兩個人的指責是相同的，只是工作時間不同，他們的更改很可能有沖突。于是，要么兩個人消極地等待對方進行修改然后自己再修改，要么兩個人過于積極以至于每次更改都要仔細看看對方的代碼有沒有和自己的沖突，費勁地更改代碼。而版本控制工具則提供了一種更好的方法，可以自動合并修改（如果沒有沖突的話），或者，如果遇到沖突就對用戶進行提示。

為了更好地進行團隊協作開發，我們引入 git 作為版本控制工具。

Git 以及 Github 簡介

Git 是 Linus 在開發 Linux 內核時用于替換 Bitkeeper 版本控制工具（該工具不是免費的）而寫的一個開源的分布式版本控制軟件。而Github 是一個代碼托管網站。而代碼托管的意思是允許人們把代碼放到 Github ，并為團隊開發提供一種比較簡單的代碼同步方法。Git是一個分布式的版本控制工具。分布式主要是針對已有的 SVN 、CVS 受中央控制的版本控制工具而言的。在git里，每個代碼庫在相互獨立的同時，又可以相互交換代碼（通過push/pull）進行代碼的交換。這里主要介紹Github在 Windows 上的使用。

安裝 Github for Windows

在http://windows.github.com/上下載 Github for Windows ，按提示安裝即可。在安裝過程中，git 的命令行版本也會一并安裝。雖然在 Windows 下大多數應用都是基于圖形界面的，但是使用 git 還是很有必要用命令行。

Github for Windows 實際上是 Github 網站的客戶端版本，有網站上的一切功能，并且，為上傳、更新位于 github.com 的代碼庫進行了良好的支持。使用 Github 帳號登陸以后，在圖形界面里可以輕易地創建代碼庫。

Git 常用命令使用

命令行里git的命令列表以及解釋：

• git clone <address>：復制代碼庫到本地。
• git add <file> ...：添加文件到代碼庫中。
• git rm <file> ...：刪除代碼庫的文件。
• git commit -m <message>：提交更改，在修改了文件以后，使用這個命令提交修改。
• git pull：從遠程同步代碼庫到本地。
• git push：推送代碼到遠程代碼庫。
• git branch：查看當前分支。帶*是當前分支。

  • git branch <branch-name>：新建一個分支。
  • git branch -d <branch-name>：刪除一個分支。
  </ul> </li>
  • git checkout <branch-name>：切換到指定分支。
  • git log：查看提交記錄（即歷史的 commit 記錄）。
  • git status：當前修改的狀態，是否修改了還沒提交，或者那些文件未使用。
  • git reset <log>：恢復到歷史版本。
  </ul>

  看了這些命令以后，對里面的名詞肯定有所疑問。代碼庫應該很好理解，就是存放代碼的地方，而在 git clone 里，代碼庫一般指的是遠程的代碼庫，即 github 給出的鏈接。而分支則是開發的一個階段或者一個旁系版本，至于怎么定則取決于使用者了。例如，有一個分支叫做stable，代表里面的代碼是經過測試的、穩定的；另一個分支叫dev，則是保存開發中的代碼，不一定經過足夠測試。

  一般的開發流程

  一般使用 git 的流程： 1. 編輯文件，更新代碼。 2. 添加代碼到當前待提交的更改列表中：git add <修改的文件>。 3. 提交當前修改作為一個記錄：git commit -m '修改了<修改的文件>，原因是：……'。 4. 更新代碼：git push。

  常見問題

  這里的常見問題只是基于我的使用經歷，如果有錯或者有更好的想法，留言通知我~

  1. 什么時候提交更改記錄（ commit ）？

     這個問題其實很隨意，新增一個特性或者破壞了原有結構，甚至每一次改動都可以作為提交更改記錄的依據。

     </li>

  2. 什么時候推送更新（ push ）？

     一般來說，更改了項目的結構（包括文件、目錄），就應該盡快推送更新，以通知其他協作者跟進這個更新。對于其它細微的修改，沒有破壞到別人的工作的，可以隨自己的想法更新（如果是提交了某些激動人心的特性，就趕緊推送給別人分享吧~ ）

     不過切記，更改了目錄結構、文件結構等一定要在commit中寫清楚，否則別人可能還是一頭霧水。

     </li>

  3. 什么時候和遠程同步（ pull ）？

     每次開始工作前都應該同步一下，以免自己的修改和別人沖突或者別人做了結構性的調整和自己的修改不協調了。

     </li>

  4. 分支（ branch ）的使用？

     至于遠程分支的使用，可以參考 github 的推薦方法功能劃分方法，來自，就是說，每一個功能設定一個分支，當修改完成以后再合并到 master ，保證 master 分支是可用的。

     對于本地分支（就是本地代碼庫的分支了，這兩個是不同的概念哦，記得 git 是分布式的，每個代碼庫有關聯但又互相獨立），使用就比較隨便了。主要是方便自己開發即可。

     </li>

  5. 怎么解決沖突（ conflict ）？

     在團隊開發中，同時對某一個文件進行改寫是常見的事，但是我們應該盡可能避免。每個模塊之間應該進行良好的隔離。但一旦遇到沖突，git也有很好的解決方法。

     在同步代碼的過程中，git會自動檢查沖突，并嘗試進行自動合并。最好的情況應該是大家同時修改一個文件，但是大家修改的地方不同了。在這樣的情況下，git會進行非沖突合并，這時，在調用 git pull 的時候，git會嘗試進行非沖突合并。

     而在合并過程中有沖突的時候， git 會把修改記錄直接保存在文件中，讓開發者判斷文件如何解決合并。例如，在一個描述文件中同時修改了一句話，在合并的時候，git會這么做：

     <<<<<<< HEAD
     
     It's not a project cool enough for you to enjoy the code but a mix of my thoughts in the year 2012~2013. I didn't know where the project leads to. Hope it will became useful after practice.
     It's not a project cool enough for you to enjoy the code but it's a mix of my thoughts in the year 2012~2013. I didn't know where the project leads to. Hope it will became useful after practice.
     >>>>>>> 2b41083cf969979d8e4a1eedc987976af544d129</code></pre> 
     即把兩個更改都寫在文件上，但是用=======來區別發生沖突的位置，在=======以上是 HEAD，即本地的代碼；而=======以下則是來自遠程的更改了。這個時候，你可以選擇保留遠程或本地的修改或者都不要（簡單地說，把不需要的內容刪除即可）。
     </li>
     
     
     怎樣恢復到歷史版本（ reset ）？
     
     使用 git log 查看更改記錄，記住其中的 commit 版本號，然后，運行 git reset <log> --hard 即可（ <log> 即 commit 版本號）。另外， git reset HEAD 可以恢復到上一個 commit 版本。
     
     如果只是想把更改狀態切換到某一個歷史記錄，那么，可以 git reset <log> 這樣，文件不會恢復到歷史版本，但是，在這個記錄后修改的文件會被標記為已修改，但未添加修改記錄里。
     </li>
     </ol>
     </div>
     </div>
     </div>
     </div>
     來自：https://github.com/neuola/neuola-legacy/wiki/github%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97