github分支管理

在git中，每當我們commit的時候，git將會把提交的時間串成一條線，這條線就是一個分支，也就是主分支，也叫master分支（默認情況下）。嚴格來說，HEAD並沒有指向提交，而是指向了master，master指向的提交。每次提交的時候，master就會將當前提交時間串在時間線上，並且指向當前時間點，隨着不斷的提交， master分支也越來越長，當我們使用git log命令的時候，查看到的就是這條時間線。
當我們創建一個新的分支，比如叫 dev，現在dev指向的提交就是master指向的提交，但是HEAD現在指向dev，現在我們再提交的時候就是提交在dev分支了，而master分支不變。當我們在dev分支上完成開發工作，檢查無誤後，就可以將dev分支master分支上了。
應用場景：當我們的軟件開發完成1.0版本後，現在有了新的需求，要開發2.0版本。但不幸的是，在開發到一半的時候，1.0版本發現了幾個bug，沒辦法，改吧，但是我們顯然不能再現在的工程基礎上修改，如果在現在工程上修改的話，1.0版本的軟件將會帶有部分2.0版本的特性或者功能，成了1.5版本。這時候，我們在完成1.0版本後，就可以新建一個分支，在新的分支上進行新的開發，在確認完成後，再合併到主分支。
操作如下：

1.創建並切換到新的分支

git checkout -b dev
-b參數表示創建並切換到新的分支，相當於下面兩條命令

git branch dev
git checkout dev

然後使用git branch命令查看所有的分支，在當前所在的分支上會有*提示，如下：

現在我們處於dev分支下，Test.txt文件裏面沒有任何內容，對Test.txt進行修改並提交。

git add Test.txt
git commit -m "branch test"

2. 合併分支

然後切換到master分支，再去查看Test.txt文件中的內容，發現是空白的。這是因爲我們提交的內容在dev分支上，master分支並沒有做什麼改變。效果如下圖：

然後對兩個分支進行合併,合併完成後刪除dev分支

git merge dev
git branch -d dev

合併完成後發現Test.txt文件內容與dev分支下的完全相同

3. 合併時的衝突

不幸的是，沒有什麼是一帆風順的，合併時遇到了衝突怎麼辦？系統給出了這麼個提示

D:\GitRepositorys [master]> git merge dev
warning: Cannot merge binary files: Test.txt (HEAD vs
Auto-merging Test.txt
CONFLICT (content): Merge conflict in Test.txt
Automatic merge failed; fix conflicts and then commit
D:\GitRepositorys [master +0 ~0 -0 !1 | +0 ~0 -0 !1]>

這個衝突貌似只能手動修改，打開衝突的文件，查看衝突提示，手動修改完成後再提交、合併
（其實我也不大懂，只是建議不要在兩個分支上同時修改同一個文件）

4 分支管理策略

4.1 分支合併模式

通常情況下，git在合併分支的時候會用Fast forward模式，但是在這種模式下，刪除分支後，會丟掉分支信息，也就是分支提交的信息，如果強制禁用Fast forward模式，git在葛冰分支的時候會生成一個新的commit，語法格式如下（將dev分支合併到master分支上）：
git merge --no-ff -m "禁用Fast forward 模式合併分支" dev

4.2 分支策略

首先，master分支是非常穩定的，也就是僅僅用來發布新的版本。
其次，從master分支上創建一個新的分支（dev），每個開發人員都有自己的分支（從dev分支上創建的），推送代碼時只要將自己的分支和dev分支合併就可以了，
最後，當藥發佈新版本時，只需要將dev分支合併到master分支就可以了

4.3 bug分支

當你正在進行開發時，突然間發現了以前的一個bug，需要立刻修復，但是你現在的開發工作還沒有完成，沒有辦法提交，git提供了一個stash功能，可以把當前場景保存起來，等以後可以恢復現場：git stash，現在用git status查看工作區，是乾淨的了，可以創建一個新的分支（首先要確定從哪個分支上修復bug），修復完成後，合併並刪除bug分支。
現在我們需要恢復現場，使用git stash list命令來查看保存了哪些現場，恢復現場有兩種方式，一是用git stash apply stash@{NUM} 或者是用git stash pop，區別是前者不會刪除stash，恢復現場後需要收到執行 git stash drop來刪除。當然，也可以多次stash然後使用git stash apply stash@{num}來恢復指定的現場。

5. 多人協作

5.1 克隆倉庫

當你從遠程倉庫克隆時，實際上Git自動把本地的master分支和遠程的master分支對應起來了，並且，遠程倉庫的默認名稱是origin。

要查看遠程庫的信息，用git remote：

$ git remote
origin

或者，用git remote -v顯示更詳細的信息：

$ git remote -v
origin  git@github.com:michaelliao/learngit.git (fetch)
origin  git@github.com:michaelliao/learngit.git (push)

上面顯示了可以抓取和推送的origin的地址。如果沒有推送權限，就看不到push的地址。

5.2 推送分支

推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：
$ git push origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev

5.3 抓取分支

多人協作時，大家都會往master和dev分支上推送各自的修改。當我們從遠程倉庫克隆的時候，我們只能看到本地master分支，如果我們要在其他分支上開發，就必須創建origin的其他分支到本地，或者說建立遠程分支和本地分支的關聯:
git checkout -b dev origin/dev,然後，我們就可以在dev分支上繼續修改，然後將修改後的項目推送到遠程

6. 標籤管理

6.1 創建標籤

首先切換到需要打標籤的分支上，git checkout branch-name,
然後使用命令git tag <name>就可以了，默認標籤是打在最新提交上的，如果我們想要打在以前的提交上，可以使用git log查看以前提交的commit id，然後使用git tag <name> <commit id>就可以了。可以使用命令git tag查看標籤，但是標籤不是按照時間順序排序的，而是按照字母順序排序。在打標籤的時候可以帶有說明，語法格式如下：
git tag -a <tag-name> -m "comment" <commit id>
使用命令git show <tag-name>可以查看詳細信息。

6.2 刪除標籤

如果標籤打錯了，可以使用git tag -d <tag-name>來刪除指定的標籤，默認情況下，標籤不會自動推送到遠程。如果想把某個標籤推送到遠程，可以使用git push origin <tag-name>，或者一次性推送所有本地的標籤:git push origin --tags,如果標籤已經推送的遠程倉庫，想要刪除遠程倉庫的標籤需要如下兩步:
首先刪除本地標籤 git tag -d <tag-name>
然後從遠程刪除 git push origin :refs/tags/<tag-name>

github分支管理