[Todo] Git & 版本控制學習

下面這篇寫的很是好。git分支介紹，有圖。好好看這一篇，就懂了：

http://www.open-open.com/lib/view/open1328069889514.html

該系列還有很多文章，在頁面下面的列表裏，有時間能夠看看（Todo）。

 

 下面是一些筆記：

經過此語法，你能夠把本地分支推送到某個命名不一樣的遠程分支：若想把遠程分支叫做awesomebranch，
能夠用 git push origin serverfix:awesomebranch 來推送數據 （本地serverfix，遠程awesomebranch）。

好比某些項目你不是維護者，但想幫點忙的話，最好用衍合：先在本身的一個分支裏進行開發，當準備向主項目提交補丁的時候，
根據最新的origin/master 進行一次衍合操做而後再提交，這樣維護者就不須要作任何整合工做
（譯註：其實是把解決分支補丁同最新主幹代碼之間衝突的責任，化轉爲由提交補丁的人來解決。），
（主幹維護者）只需根據你提供的倉庫地址做一次快進合併，或者直接採納你提交的補丁。

呃，奇妙的衍合也並不是天衣無縫，要用它得遵照一條準則：
一旦分支中的提交對象發佈到公共倉庫，就千萬不要對該分支進行衍合操做。
若是你遵循這條金科玉律，就不會出差錯。不然，人民羣衆會仇恨你，你的朋友和家人也會嘲笑你，唾棄你。

在進行衍合的時候，實際上拋棄了一些現存的提交對象而創造了一些相似但不一樣的新的提交對象。若是你把原來分支中的提交對象發佈出去，
而且其餘人更新下載後在其基礎上開展工做，而稍後你又用 拋棄這些提交對象，把新的重演後的提交對象發佈出去的話，
你的合做者就不得不從新合併他們的工做，這樣當你再次從他們那裏獲取內容時，提交歷史就會變得一團糟。
git rebase

若是把衍合當成一種在推送以前清理提交歷史的手段，並且僅僅衍合那些還沒有公開的提交對象，就沒問題。
若是衍合那些已經公開的提交對象，而且已經有人基於這些提交對象開展了後續開發工做的話，就會出現叫人沮喪的麻煩。

下面是一些從文中摘錄出的可以幫助理解的圖：

 

幾個注意點：

1. 修改了文件的時候，必需要 git add，不add的話commit提交的文件就不對。git add 和 git stage是一個意思，是把文件提交到中間的stage區（注：git文件有三個區：working, stage, repository）.

能夠用 git diff --cached 或 git diff --staged 來查看stage中的文件diff，兩個命令同一個意思。

 

2. 這篇文章講了比較詳細的和遠程repository衝突的問題。

http://www.cnblogs.com/cj2014/p/5557654.html

當沒有對本地進行 git fetch 或 git pull的時候（git pull = git fetch + merge to local，而git fetch指的是同步到本地repository，而不是working directory），若是遠端有改動，本地也有改動，就會發生衝突，就要進行衝突解決。

通常來說，都是須要人爲解決的。

解決的方法就是 git pull, add, commit, mergetool等命令的組合。

1). git pull: 提示衝突

    2). 提交(git add --all; git commit)

    3). git pull

    4). git mergetool

    5). git pull
    6). git commit 
         [216-fixed-area-walk d228a46] Merge branch '216-fixed-area-walk' of 192.168.1.51:IGV/IGV01-SW into 216-fixed-area-walk

    7). git add --all
    8). git commit
    9). git push origin 216-fixed-area-walk

 

再複習一下普通的提交到遠端的方式（注意不要忘了git add）

1. git pull

2. git add --all

3. git commit

4. git push origin 216-fixed-area-walk

 

下面這篇文章寫的不錯：

http://blog.csdn.net/kesenhoo/article/details/7654351

分佈式版本控制系統（ Distributed Version Control System，簡稱 DVCS ）面世了。在這類系統中，諸如Git，Mercurial，Bazaar 還有 Darcs 等，
客戶端並不僅提取最新版本的文件快照，而是把原始的代碼倉庫完整地鏡像下來。

文章列表在這裏：

http://blog.csdn.net/kesenhoo/article/category/1165624

 

git分支的介紹(可是圖不清楚)，其實複製了第一篇文章，能夠忽略：

http://blog.csdn.net/wh_19910525/article/details/7470964

裏面提到：Git 又是如何建立一個新的分支的呢？答案很簡單，建立一個新的分支指針。

在 Git 中，它是一個指向你正在工做中的本地分支的指針（譯註：將 HEAD 想象爲當前分支的別名。）。

 

關於fast-forward, no-ff, squash等的解釋，下面寫的不錯

http://blog.csdn.net/chen930724/article/details/50174657

fast-forward方式就是當條件容許的時候，git直接把HEAD指針指向合併分支的頭，完成合並。屬於「快進方式」，不過這種狀況若是刪除分支，則會丟失分支信息。
由於在這個過程當中沒有建立commit

squash 是用來把一些沒必要要commit進行壓縮，好比說，你的feature在開發的時候寫的commit很亂，那麼咱們合併的時候不但願把這些歷史commit帶過來，
因而使用--squash進行合併，此時文件已經同合併後同樣了，但不移動HEAD，不提交。須要進行一次額外的commit來「總結」一下，而後完成最終的合併。

--no-ff指的是強行關閉fast-forward方式。