Git分支管理入門

以前那篇文章《Git基礎入門》只是簡單講了一下git最基礎最簡單的用法，可是git還有一個很是重要的功能就是分支，默認狀況下只有一個master分支，咱們能夠直接在master分支開發，徹底沒問題， 可是當你的項目有十幾個甚至幾十我的同時在開發的時候，若是都使用master分支，就會很是容易出現衝突、甚至出現代碼被覆蓋的問題，並且上線也是個問題，你不知道哪些文件能夠上，哪些不能夠上，很容易把一些未經測試的代碼上線，這時候就須要啓用分支功能。

1. git branch

默認狀況下咱們都是在master分支下，咱們可使用 git branch 命令查看當前所在分支：

jwang@jwang:~/git_demo$ git branch
* master
複製代碼

使用 -r 參數能夠查看遠程分支的狀況：

jwang@jwang:~/git_demo$ git branch -r
  origin/HEAD -> origin/master
  origin/master
複製代碼

若是須要建立分支，則只需在 git branch 加上分支的名稱便可，若是你想新建一個dev分支，操做以下：

jwang@jwang:~/git_demo$ git branch dev
jwang@jwang:~/git_demo$ git branch
  dev
* master
複製代碼

這裏能夠看到咱們已經建立了一個dev分支，可是這時候咱們還在master分支，並無切換到dev分支。

2. git checkout

這個命令以前說過，可是在分支裏面它還有另外一個功能，那就是切換分支，好比若是你想切換到dev分支，用法以下：

jwang@jwang:~/git_demo$ git checkout dev
Switched to branch 'dev'
jwang@jwang:~/git_demo$ git branch
* dev
  master
複製代碼

這時候咱們全部的pull，commit，push操做都是在當前dev分支，並不影響master分支，可見分支一大好處就是隔離代碼，開一個分支寫啥都行，不會影響其它人。

可是有一點須要注意，當你在dev分支使用 git push 推代碼的時候你可能會遇到下面這個問題：

fatal: The current branch dev has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin dev
複製代碼

這個報錯的意思是當前分支沒有上游分支，什麼意思呢？以前說過這個，在默認狀況下，git push使用simple模式，只會把代碼推送到你 git pull 拉取代碼的分支上，可是這是遠程服務器並無dev分支，咱們只是在本地建立了這個dev分支。

可是這個很容易解決，咱們只須要這麼作 git push origin dev 就能夠：

jwang@jwang:~/git_demo$ git push origin dev
Username for 'https://github.com': wangbenjun@gmail.com
Password for 'https://wangbenjun@gmail.com@github.com': 
Counting objects: 3, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 282 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: 
remote: Create a pull request for 'dev' on GitHub by visiting:
remote:      https://github.com/wangbjun/git_demo/pull/new/dev
remote: 
To https://github.com/wangbjun/git_demo
 * [new branch]      dev -> dev
複製代碼

不過爲了方便之後提交代碼，咱們可使用 git push --set-upstream origin dev 命令設置上游分支，這樣咱們在使用 git pull、git push 命令的時候就不會報錯了，它會默認跟蹤dev分支。

第一次使用git的人會很好奇這個origin究竟是啥意思？按個人理解，這個origin其實就是指遠程分支，git pull origin dev命令就是從遠程的dev分支上拉代碼。固然你能夠在從master或者其它分支拉取代碼，不過通常不建議從其它遠程分支拉代碼。

3. git merge

當你在這個dev分支完成開發，測試也沒問題了，你就須要把這個dev分支合併到master分支，這時候就須要使用merge命令，這個命令須要明白是把誰合併到誰。假如你在dev分支執行 git merge master，這就表示是把master分支合併到dev，最終代碼在dev上。有些新手會理解錯爲把dev分支合併到master，這點須要注意。

在哪一個分支上面合併都同樣，你也能夠在master分支上合併dev，反正最終都是一份代碼，可是從項目管理的角度來講，應該先在dev分支合併master，而後再測試，由於master分支可能已經有別人提交的新的修改，你須要把這些修改合併過來。

說到分支就不得不說到衝突，這是不少新人最懼怕的事情，所謂衝突就是2我的在不一樣分支改動了同一行代碼，這時候git就懵逼了，我到底保留哪一份呢？按提交時間前後順序？最靠譜的方式固然是把衝突留給合併代碼的人解決。

有不少新人不知道怎麼解決衝突就直接把別人寫的代碼覆蓋掉了。。。這樣的事情很常見，雖然git有歷史記錄，代碼丟是丟不了，可是解決衝突確實是個很是棘手的事情。

爲了解決衝突，你必須對你所寫的代碼瞭解，同時須要和另一個修改代碼的人溝通，2我的協商一下最後保留哪些代碼，千萬不能獨斷獨行。講道理，若是一個項目結構分層合理，同時你又是常常pull代碼的話，衝突是不多見的。

jwang@jwang:~/git_demo$ git merge master
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
複製代碼

解決衝突的方式其實不不難，使用圖形化界面工具最方便，若是你不使用，你只須要找到發生衝突的文件，通常內容會以下：

# git_demo
git demo

This is a Test!

function add($a, $b)
{
    return $a+$b;
}

<<<<<<< HEAD
echo "This is a dev!";
 $a = add(1,2);
 var_dump($a);
=======
nothing to say
>>>>>>> master
複製代碼

請注意 <<<<<<< HEAD ...code... ======= ...code... >>>>>>> master 這3個標識中間的代碼，其中上半段代碼表示的是目前分支的代碼，下半段表示的是master分支的代碼。

你只需根據本身的需求刪掉不須要的代碼，保留須要的就行，好比說在這個例子裏面，我只想刪掉var_dump，我就能夠這樣改：

# git_demo
git demo

This is a Test!

function add($a, $b)
{
    return $a+$b;
}

echo "This is a dev!";
 $a = add(1,2);

nothing to say
複製代碼

而後從新commit就行，最後若是沒問題的話push就行。

通常狀況下，若是你不解決衝突的話是不容許你push代碼的，可是你能夠強制push，這樣就會把衝突的代碼（其實就是上面帶着<<<<<符號的代碼）push到遠程分支，這樣固然是很差滴，千萬不要幹這種坑事。

總結：

在實際開發中，咱們通常遵循大概這樣的流程，好比小A和小B如今要開始作一個項目的大功能，這個功能開發週期比較長，這時候由小A建立開發分支，小A的操做以下：

1.小A首先切換到master分支： git checkout master
2.而後更新代碼： git pull
3.建立功能分支： git branch -b new_feature
4.提交分支到遠程服務器供小B拉取： git push origin new_feature
5.小B拉取功能分支： git checkout new_feature && git pull
6.期間小A和小B共同開發，不停的pull和push
7.功能開發完成，測試完成後合併到master分支，解決可能出現的衝突
8.切換到master分支，合併dev，最後提交代碼到遠程倉庫，若是沒問題的話就能夠上線了
複製代碼

這是最簡單的一個分支用法，能夠保證一組人在同一個分支開發，同時不會影響線上的代碼。對於複雜的項目我建議能夠參考 git flow 模型的用法，更加專業合理。