本文面向初次接觸版本控制系統的git使用者，旨在介紹一些關於版本控制和git的簡單概念。git是目前最先進的版本控制系統，擁有最多的使用者數量並管理著數量龐大的實際軟體專案；風靡全球的github更是讓git版本控制系統名聲大震。本文以「版本控制系統」為切入點，以國內的gitcafe平台為例，介紹相關概念和簡單的git用法。文中並不涉及過多的git實際操作，文末推薦更多的git學習資源。
如果對「版本控制」沒有概念，那真是沒法用git。
所以我們來看乙個例子：假設大四畢業生小張在寫畢業**，寫好初稿後經常刪改，甚至還會在第二天把前一天刪掉的東西找回來。如果他動點腦子，就不會只在乙個文件中改來改去，而會在資料夾中有：
12
3
4
5
6
7
8
9
10
畢業**_初稿.doc畢業**_修改
1.doc
畢業**_修改
2.doc
畢業**_修改
3.doc
畢業**_完整版
1.doc
畢業**_完整版
2.doc
畢業**_完整版
3.doc
畢業**_最終版
1.doc
畢業**_最終版
2.doc
……
看起來是不是很鬱悶啊？小張當然也鬱悶了，因為自己總是改不好，所以他把自己的**發給女朋友（是學霸），求幫忙；與此同時他自己也在繼續修改。第二天就有了：
12
畢業**_最終版
3.doc
畢業**
_女友版
1.doc
他女友畢竟是學霸，當然給他的**做了比較大的修改，此時小張雖然看到了希望，但還要糾結著做一件事情：把上面兩個版本的**合併成：
1 畢業**_死也不改版.
doc等合併好，已是凌晨三點半。小張無比怨念：這樣子真是沒法和女友開心的玩耍了呢！
怎麼辦？
小張想，如果能有個什麼東西來幫忙控制一下這該死的版本，那真是謝天謝地了！就像這樣：
版本修改人
說明日期
初稿小張
這是初稿
day1
修改1小張
修改目錄
day2
修改2小張
合併段落
day3
…………
…………
最終版2
小張***
day7
死也不改版
女友bala
day8
這樣就不用手動控制那麼多版本啦！
所以，所謂「版本控制系統」，就是來解決這類問題的。
沒錯，git就是乙個版本控制軟體。在進行軟體開發時，乙個團隊的人靠使用git，就能輕鬆管理好專案版本，做好專案的追蹤和輔助進度控制。確切的講，git是一款分布式版本控制系統。這個「分布式」，要和「集中式」放在一起理解。
所謂「集中式版本控制」，就好比這乙個團隊中，版本庫都集中在一台伺服器上，每個開發者都要從伺服器上獲取最新的版本庫後才能進行開發，開發完了再把新的版本提交回去。
而「分布式版本控制」，則是這個團隊中每個人的電腦上都會有乙份完整的版本庫，這樣，你工作的時候，就不需要聯網了，因為版本庫就在你自己的電腦上。既然每個人電腦上都有乙個完整的版本庫，那多個人如何協作呢？比方說你在自己電腦上改了檔案a，你的同事也在他的電腦上改了檔案a，這時，你們倆之間只需把各自的修改推送給對方，就可以互相看到對方的修改了。
和集中式版本控制系統相比，分布式版本控制系統的安全性要高很多，因為每個人電腦裡都有完整的版本庫，某乙個人的電腦壞掉了不要緊，隨便從其他人那裡複製乙個就可以了。而集中式版本控制系統的**伺服器要是出了問題，所有人都沒法幹活了。
在實際使用分布式版本控制系統的時候，其實很少在兩人之間的電腦上推送版本庫的修改，因為可能你們倆不在乙個區域網內，兩台電腦互相訪問不了，也可能今天你的同事病了，他的電腦壓根沒有開機。因此，分布式版本控制系統通常也有一台充當「**伺服器」的電腦，但這個伺服器的作用僅僅是用來方便「交換」大家的修改，沒有它大家也一樣幹活，只是交換修改不方便而已。
版本，不是檔案的版本麼？這個版本庫是什麼意思？
如果能意識到控制的是檔案的版本，那就離理解版本庫只差一步了（最關鍵的一步）。
程式要記錄專案的版本號，最簡單的方法就是把版本相關的資訊放在某檔案裡，持續寫入檔案便視為版本更新。所以，當我們在乙個目錄中執行命令：
12
$git init
#git初始化的命令，用於新建版本庫
這個目錄中就會預設產生乙個新目錄：
1 .git/沒錯，這就是我們剛剛新建的版本庫，它將預設記錄當前目錄（直接包含.git的這個目錄，下文中叫做「專案目錄」）中任何檔案的改動。如果把這個版本庫刪除了，這裡面記錄的檔案版本就都沒有了，專案目錄中的檔案當前是什麼樣子，那就一直是什麼樣子，沒法恢復到以前的版本了。如果想讓git忽視專案目錄中的什麼檔案（比如程式快取等），可以在.gitignore中寫清楚那些檔案。
在實際應用中，git有非常多的用法，而本文是面向git完全初學者，所以我們要從最基本的開始做。
比如，在剛才建好的版本庫中，a新建了readme檔案，並在裡面寫了東西。寫好後他想給專案做個版本，就需要這樣：
12
$git add readme
$git commit -m "add readme"
第乙個命令是告訴git要追蹤什麼檔案，第二個命令是進行提交，並對此次提交做個簡答說明。當然，今後他再對readme做什麼修改，都可以這樣做。git會自動為此次提交生成乙個16進製制的版本號。
如果此時他檢視本地的版本庫，就會發現最新的一次提交是在剛才，提交說明為：add readme。
然後，他要把專案的版本庫更新到gitcafe上，當然這時候專案本身已經在gitcafe上建立好了。他只需要：
1 $git push origin master
這行命令應該這樣理解：a已經在本地把專案最新的版本做好了，他要發到gitcafe上，以便團隊裡其他人都能收到這個新的版本，於是他執行git push；push的目的地是origin，這其實是個名字，意義為該專案在gitcafe上的位址；推送的是本地的master分支。
這個時候，gitcafe上專案的版本號與a本地的最新版本號一致。
分支是版本控制裡面的乙個概念：在專案做大了之後，如果要在原基礎上進行擴充套件開發，最好新建乙個分支，以免影響原專案的正常維護，新的分支開發結束後再與原來的專案分支合併；而在乙個專案剛開始的時候，大家一般會在同乙個分支下進行開發.這是一種相對安全便捷的開發方式。此時，小組裡成員b對專案其他檔案做了一些更改，同樣也在本地做了一次提交，然後也想推到gitcafe上面。他執行了
git push origin master命令，結果發現提交被拒絕。這要做如何解釋？
仔細想想，最開始的時候，a和b是在同乙個版本號上做不同的更改，這就會分別衍生出兩個不同的版本號。a先把自己的版本推到gitcafe上，此時gitcafe上的版本庫與b本地版本庫相比，差異很大，主要在於b這裡沒有a的版本記錄，如果b這時把自己的版本強制同步到gitcafe上，就會把a的版本覆蓋掉，這就出問題了。
所以b進行了如下操作：
1 $git pull
這樣子，b先把gitcafe上的版本庫和自己的版本庫做乙個合併，這個合併的意義在於：b通過gitcafe，把a剛才新增的版本加了進來，此時b本地的版本庫是整個專案最新的，包括專案之前的版本、剛剛a新增的版本和b自己新增的版本。
這之後，b再次執行git push origin master，成功地把自己的版本推到了gitcafe上。如果a想要推送新的版本，也要像b之前這樣折騰一番才行。
當然可以！
最後還有一本不錯的中文書籍：
不過，本文就要到此為止了，因為再往下寫就會涉及更多更深的git操作實踐，而這些內容在上面給出的資料中已經整理好。
本文的目的在於解決身邊乃至更多開發者同時入門版本控制和git時候遇到的困惑，希望能對各位初學者起到積極的作用。
如果您有更好的意見或建議，歡迎與我討論：）
Zend Framework入門指引
安裝篇 windows平台 安裝tortoisesvn。tortoisesvn是svn在win下的客戶端。安裝tortoisesvn的目的是為了獲取最新的zf原始碼，如果你使用zend定期發布的zf的原始碼，可以跳過這一步。為zf新增路徑。編輯php.ini wamp的php.ini在apache ...
C 入門指引
1 語言書籍 c primer 第四版 c primer習題解答 2 gui c 方面的gui庫有很多種，比如mfc wtl wxwidgets qt。這些gui庫都各有自己的特點，其實我們只要先了解一種就可以了，只要深入了解了一種gui庫，需要的時候再學習其他的就夠了，本質上都差不多，很快就可以上...
VueJs學習入門指引
新產品開發決定要用到vuejs，總結乙個vuejs學習指引。3.按照文件學習vuejs 最重要 vuejs入門最重要的學習資料是官網的學習指引 建議把官方的指引教程的基礎部分看看，這個指引寫的不錯，也比較容易理解，能覆蓋大部分的知識點。vuejs核心是 雙向資料繫結 和 元件 指引教程基本都是圍繞這...