上推 pac opp 關聯 commit 除了 快速 指定 HR

一、分支的創建與合並

　　在版本回退裏，你已經知道，每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，在Git裏，這個分支叫主分支，即master分支。HEAD嚴格來說不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是當前分支。

一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能確定當前分支，以及當前分支的提交點：

每次提交，master分支都會向前移動一步，這樣，隨著你不斷提交，master分支的線也越來越長：

當我們創建新的分支，例如dev時，Git新建了一個指針叫dev

，指向master相同的提交，再把HEAD指向dev，就表示當前分支在dev上：

你看，Git創建一個分支很快，因為除了增加一個dev指針，改改HEAD的指向，工作區的文件都沒有任何變化！

不過，從現在開始，對工作區的修改和提交就是針對dev分支了，比如新提交一次後，dev指針往前移動一步，而master指針不變：

假如我們在dev上的工作完成了，就可以把dev合並到master上。Git怎麽合並呢？最簡單的方法，就是直接把master指向dev的當前提交，就完成了合並：

所以Git合並分支也很快！就改改指針，工作區內容也不變！

合並完分支後，甚至可以刪除dev分支。刪除dev分支就是把dev

指針給刪掉，刪掉後，我們就剩下了一條master分支：

真是太神奇了，你看得出來有些提交是通過分支完成的嗎？

下面開始實戰。

首先，我們創建dev分支，然後切換到dev分支：

1 $ git checkout -b dev
2 Switched to a new branch ‘dev‘

git checkout命令加上-b參數表示創建並切換，相當於以下兩條命令：

$ git branch dev
$ git checkout dev
Switched to branch ‘dev‘

然後，用git branch命令查看當前分支：

1 $ git branch
2 * dev
 
3   master

git branch命令會列出所有分支，當前分支前面會標一個*號。

然後，我們就可以在dev分支上正常提交，比如對readme.txt做個修改，加上一行：

Creating a new branch is quick.

然後提交：

1 $ git add readme.txt 
2 $ git commit -m "branch test"
3 [dev fec145a] branch test
4  1 file changed, 1 insertion(+)

現在，dev分支的工作完成，我們就可以切換回master分支：

1 $ git checkout master
2 Switched to branch ‘master‘

切換回master分支後，再查看一個readme.txt文件，剛才添加的內容不見了！因為那個提交是在dev分支上，而master分支此刻的提交點並沒有變：

現在，我們把dev分支的工作成果合並到master分支上：

1 $ git merge dev
2 Updating d17efd8..fec145a
3 Fast-forward
4  readme.txt |    1 +
5  1 file changed, 1 insertion(+)

git merge命令用於合並指定分支到當前分支。合並後，再查看readme.txt的內容，就可以看到，和dev分支的最新提交是完全一樣的。

註意到上面的Fast-forward信息，Git告訴我們，這次合並是“快進模式”，也就是直接把master指向dev的當前提交，所以合並速度非常快。

當然，也不是每次合並都能Fast-forward，我們後面會講其他方式的合並。

合並完成後，就可以放心地刪除dev分支了：

1 $ git branch -d dev
2 Deleted branch dev (was fec145a).

刪除後，查看branch，就只剩下master分支了：

1 $ git branch
2 * master

因為創建、合並和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合並後再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。

二、解決沖突

人生不如意之事十之八九，合並分支往往也不是一帆風順的。

準備新的feature1分支，繼續我們的新分支開發：

1 $ git checkout -b feature1
2 Switched to a new branch ‘feature1‘

修改readme.txt最後一行，改為：

1 Creating a new branch is quick AND simple.

在feature1分支上提交：

1 $ git add readme.txt 
2 $ git commit -m "AND simple"
3 [feature1 75a857c] AND simple
4  1 file changed, 1 insertion(+), 1 deletion(-)

切換到master分支：

1 $ git checkout master
2 Switched to branch ‘master‘
3 Your branch is ahead of ‘origin/master‘ by 1 commit.

Git還會自動提示我們當前master分支比遠程的master分支要超前1個提交。

在master分支上把readme.txt文件的最後一行改為：

Creating a new branch is quick & simple.

提交：

1 $ git add readme.txt 
2 $ git commit -m "& simple"
3 [master 400b400] & simple
4  1 file changed, 1 insertion(+), 1 deletion(-)

現在，master分支和feature1分支各自都分別有新的提交，變成了這樣：

這種情況下，Git無法執行“快速合並”，只能試圖把各自的修改合並起來，但這種合並就可能會有沖突，我們試試看：

1 $ git merge feature1
2 Auto-merging readme.txt
3 CONFLICT (content): Merge conflict in readme.txt
4 Automatic merge failed; fix conflicts and then commit the result.

果然沖突了！Git告訴我們，readme.txt文件存在沖突，必須手動解決沖突後再提交。git status也可以告訴我們沖突的文件：

 1 $ git status
 2 # On branch master
 3 # Your branch is ahead of ‘origin/master‘ by 2 commits.
 4 #
 5 # Unmerged paths:
 6 #   (use "git add/rm <file>..." as appropriate to mark resolution)
 7 #
 8 #       both modified:      readme.txt
 9 #
10 no changes added to commit (use "git add" and/or "git commit -a")

我們可以直接查看readme.txt的內容：

1 Git is a distributed version control system.
2 Git is free software distributed under the GPL.
3 Git has a mutable index called stage.
4 Git tracks changes of files.
5 <<<<<<< HEAD
6 Creating a new branch is quick & simple.
7 =======
8 Creating a new branch is quick AND simple.
9 >>>>>>> feature

Git用<<<<<<<，=======，>>>>>>>標記出不同分支的內容，我們修改如下後保存：

Creating a new branch is quick and simple.

再提交：

1 $ git add readme.txt 
2 $ git commit -m "conflict fixed"
3 [master 59bc1cb] conflict fixed

現在，master分支和feature1分支變成了下圖所示：

用帶參數的git log也可以看到分支的合並情況：

1 $ git log --graph --pretty=oneline --abbrev-commit
2 *   59bc1cb conflict fixed
3 |4 | * 75a857c AND simple
5 * | 400b400 & simple
6 |/
7 * fec145a branch test
8 ...

最後，刪除feature1分支：

1 $ git branch -d feature1
2 Deleted branch feature1 (was 75a857c).

工作完成。

三、分支管理策略

通常，合並分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支信息。

如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。

下面我們實戰一下--no-ff方式的git merge：

首先，仍然創建並切換dev分支：

1 $ git checkout -b dev
2 Switched to a new branch ‘dev‘

修改readme.txt文件，並提交一個新的commit：

1 $ git add readme.txt 
2 $ git commit -m "add merge"
3 [dev 6224937] add merge
4  1 file changed, 1 insertion(+)

現在，我們切換回master：

1 $ git checkout master
2 Switched to branch ‘master‘

準備合並dev分支，請註意--no-ff參數，表示禁用Fast forward：

1 $ git merge --no-ff -m "merge with no-ff" dev
2 Merge made by the ‘recursive‘ strategy.
3  readme.txt |    1 +
4  1 file changed, 1 insertion(+)

因為本次合並要創建一個新的commit，所以加上-m參數，把commit描述寫進去。

合並後，我們用git log看看分支歷史：

1 $ git log --graph --pretty=oneline --abbrev-commit
2 *   7825a50 merge with no-ff
3 |4 | * 6224937 add merge
5 |/
6 *   59bc1cb conflict fixed
7 ...

可以看到，不使用Fast forward模式，merge後就像這樣：

分支策略

在實際開發中，我們應該按照幾個基本原則進行分支管理：

首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面幹活；

那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發布時，再把dev分支合並到master上，在master分支發布1.0版本；

你和你的小夥伴們每個人都在dev分支上幹活，每個人都有自己的分支，時不時地往dev分支上合並就可以了。

所以，團隊合作的分支看起來就像這樣：

Git分支十分強大，在團隊開發中應該充分應用。

合並分支時，加上--no-ff參數就可以用普通模式合並，合並後的歷史有分支，能看出來曾經做過合並，而fast forward合並就看不出來曾經做過合並。

四、Bug分支

軟件開發中，bug就像家常便飯一樣。有了bug就需要修復，在Git中，由於分支是如此的強大，所以，每個bug都可以通過一個新的臨時分支來修復，修復後，合並分支，然後將臨時分支刪除。

當你接到一個修復一個代號101的bug的任務時，很自然地，你想創建一個分支issue-101來修復它，但是，等等，當前正在dev上進行的工作還沒有提交：

 1 $ git status
 2 # On branch dev
 3 # Changes to be committed:
 4 #   (use "git reset HEAD <file>..." to unstage)
 5 #
 6 #       new file:   hello.py
 7 #
 8 # Changes not staged for commit:
 9 #   (use "git add <file>..." to update what will be committed)
10 #   (use "git checkout -- <file>..." to discard changes in working directory)
11 #
12 #       modified:   readme.txt
13 #

並不是你不想提交，而是工作只進行到一半，還沒法提交，預計完成還需1天時間。但是，必須在兩個小時內修復該bug，怎麽辦？

幸好，Git還提供了一個stash功能，可以把當前工作現場“儲藏”起來，等以後恢復現場後繼續工作：

1 $ git stash
2 Saved working directory and index state WIP on dev: 6224937 add merge
3 HEAD is now at 6224937 add merge

現在，用git status查看工作區，就是幹凈的（除非有沒有被Git管理的文件），因此可以放心地創建分支來修復bug。

首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master創建臨時分支：

1 $ git checkout master
2 Switched to branch ‘master‘
3 Your branch is ahead of ‘origin/master‘ by 6 commits.
4 $ git checkout -b issue-101
5 Switched to a new branch ‘issue-101‘

現在修復bug，需要把“Git is free software ...”改為“Git is a free software ...”，然後提交：

1 $ git add readme.txt 
2 $ git commit -m "fix bug 101"
3 [issue-101 cc17032] fix bug 101
4  1 file changed, 1 insertion(+), 1 deletion(-)

修復完成後，切換到master分支，並完成合並，最後刪除issue-101分支：

1 $ git checkout master
2 Switched to branch ‘master‘
3 Your branch is ahead of ‘origin/master‘ by 2 commits.
4 $ git merge --no-ff -m "merged bug fix 101" issue-101
5 Merge made by the ‘recursive‘ strategy.
6  readme.txt |    2 +-
7  1 file changed, 1 insertion(+), 1 deletion(-)
8 $ git branch -d issue-101
9 Deleted branch issue-101 (was cc17032).

太棒了，原計劃兩個小時的bug修復只花了5分鐘！現在，是時候接著回到dev分支幹活了！

1 $ git checkout dev
2 Switched to branch ‘dev‘
3 $ git status
4 # On branch dev
5 nothing to commit (working directory clean)

工作區是幹凈的，剛才的工作現場存到哪去了？用git stash list命令看看：

1 $ git stash list
2 stash@{0}: WIP on dev: 6224937 add merge

工作現場還在，Git把stash內容存在某個地方了，但是需要恢復一下，有兩個辦法：

一是用git stash apply恢復，但是恢復後，stash內容並不刪除，你需要用git stash drop來刪除；

另一種方式是用git stash pop，恢復的同時把stash內容也刪了：

 1 $ git stash pop
 2 # On branch dev
 3 # Changes to be committed:
 4 #   (use "git reset HEAD <file>..." to unstage)
 5 #
 6 #       new file:   hello.py
 7 #
 8 # Changes not staged for commit:
 9 #   (use "git add <file>..." to update what will be committed)
10 #   (use "git checkout -- <file>..." to discard changes in working directory)
11 #
12 #       modified:   readme.txt
13 #
14 Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

再用git stash list查看，就看不到任何stash內容了：

$ git stash list

你可以多次stash，恢復的時候，先用git stash list查看，然後恢復指定的stash，用命令：

$ git stash apply stash@{0}

修復bug時，我們會通過創建新的bug分支進行修復，然後合並，最後刪除；

當手頭工作沒有完成時，先把工作現場git stash一下，然後去修復bug，修復後，再git stash pop，回到工作現場。

五、Feature分支

軟件開發中，總有無窮無盡的新的功能要不斷添加進來。

添加一個新功能時，你肯定不希望因為一些實驗性質的代碼，把主分支搞亂了，所以，每添加一個新功能，最好新建一個feature分支，在上面開發，完成後，合並，最後，刪除該feature分支。

現在，你終於接到了一個新任務：開發代號為Vulcan的新功能，該功能計劃用於下一代星際飛船。

於是準備開發：

1 $ git checkout -b feature-vulcan
2 Switched to a new branch ‘feature-vulcan‘

5分鐘後，開發完畢：

 1 $ git add vulcan.py
 2 $ git status
 3 # On branch feature-vulcan
 4 # Changes to be committed:
 5 #   (use "git reset HEAD <file>..." to unstage)
 6 #
 7 #       new file:   vulcan.py
 8 #
 9 $ git commit -m "add feature vulcan"
10 [feature-vulcan 756d4af] add feature vulcan
11  1 file changed, 2 insertions(+)
12  create mode 100644 vulcan.py

切回dev，準備合並：

$ git checkout dev

一切順利的話，feature分支和bug分支是類似的，合並，然後刪除。

但是，

就在此時，接到上級命令，因經費不足，新功能必須取消！

雖然白幹了，但是這個分支還是必須就地銷毀：

1 $ git branch -d feature-vulcan
2 error: The branch ‘feature-vulcan‘ is not fully merged.
3 If you are sure you want to delete it, run ‘git branch -D feature-vulcan‘.

銷毀失敗。Git友情提醒，feature-vulcan分支還沒有被合並，如果刪除，將丟失掉修改，如果要強行刪除，需要使用命令git branch -D feature-vulcan。

現在我們強行刪除：

1 $ git branch -D feature-vulcan
2 Deleted branch feature-vulcan (was 756d4af).

終於刪除成功！

開發一個新feature，最好新建一個分支；

如果要丟棄一個沒有被合並過的分支，可以通過git branch -D <name>強行刪除。

六、多人協作

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

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

1 $ git remote
2 origin

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

1 $ git remote -v
2 origin  [email protected]:michaelliao/learngit.git (fetch)
3 origin  [email protected]:michaelliao/learngit.git (push)

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

推送分支

推送分支，就是把該分支上的所有本地提交推送到遠程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：

1 $ git push origin master

如果要推送其他分支，比如dev，就改成：

1 $ git push origin dev

但是，並不是一定要把本地分支往遠程推送，那麽，哪些分支需要推送，哪些不需要呢？

• master分支是主分支，因此要時刻與遠程同步；

• dev分支是開發分支，團隊所有成員都需要在上面工作，所以也需要與遠程同步；

• bug分支只用於在本地修復bug，就沒必要推到遠程了，除非老板要看看你每周到底修復了幾個bug；

• feature分支是否推到遠程，取決於你是否和你的小夥伴合作在上面開發。

總之，就是在Git中，分支完全可以在本地自己藏著玩，是否推送，視你的心情而定！

抓取分支

多人協作時，大家都會往master和dev分支上推送各自的修改。

現在，模擬一個你的小夥伴，可以在另一臺電腦（註意要把SSH Key添加到GitHub）或者同一臺電腦的另一個目錄下克隆：

1 $ git clone [email protected]:michaelliao/learngit.git
2 Cloning into ‘learngit‘...
3 remote: Counting objects: 46, done.
4 remote: Compressing objects: 100% (26/26), done.
5 remote: Total 46 (delta 16), reused 45 (delta 15)
6 Receiving objects: 100% (46/46), 15.69 KiB | 6 KiB/s, done.
7 Resolving deltas: 100% (16/16), done.

當你的小夥伴從遠程庫clone時，默認情況下，你的小夥伴只能看到本地的master分支。不信可以用git branch命令看看：

1 $ git branch
2 * master

現在，你的小夥伴要在dev分支上開發，就必須創建遠程origin的dev分支到本地，於是他用這個命令創建本地dev分支：

1 $ git checkout -b dev origin/dev

現在，他就可以在dev上繼續修改，然後，時不時地把dev分支push到遠程：

 1 $ git commit -m "add /usr/bin/env"
 2 [dev 291bea8] add /usr/bin/env
 3  1 file changed, 1 insertion(+)
 4 $ git push origin dev
 5 Counting objects: 5, done.
 6 Delta compression using up to 4 threads.
 7 Compressing objects: 100% (2/2), done.
 8 Writing objects: 100% (3/3), 349 bytes, done.
 9 Total 3 (delta 0), reused 0 (delta 0)
10 To [email protected]:michaelliao/learngit.git
11    fc38031..291bea8  dev -> dev

你的小夥伴已經向origin/dev分支推送了他的提交，而碰巧你也對同樣的文件作了修改，並試圖推送：

 1 $ git add hello.py 
 2 $ git commit -m "add coding: utf-8"
 3 [dev bd6ae48] add coding: utf-8
 4  1 file changed, 1 insertion(+)
 5 $ git push origin dev
 6 To [email protected]:michaelliao/learngit.git
 7  ! [rejected]        dev -> dev (non-fast-forward)
 8 error: failed to push some refs to ‘[email protected]:michaelliao/learngit.git‘
 9 hint: Updates were rejected because the tip of your current branch is behind
10 hint: its remote counterpart. Merge the remote changes (e.g. ‘git pull‘)
11 hint: before pushing again.
12 hint: See the ‘Note about fast-forwards‘ in ‘git push --help‘ for details.

推送失敗，因為你的小夥伴的最新提交和你試圖推送的提交有沖突，解決辦法也很簡單，Git已經提示我們，先用git pull把最新的提交從origin/dev抓下來，然後，在本地合並，解決沖突，再推送：

 1 $ git pull
 2 remote: Counting objects: 5, done.
 3 remote: Compressing objects: 100% (2/2), done.
 4 remote: Total 3 (delta 0), reused 3 (delta 0)
 5 Unpacking objects: 100% (3/3), done.
 6 From github.com:michaelliao/learngit
 7    fc38031..291bea8  dev        -> origin/dev
 8 There is no tracking information for the current branch.
 9 Please specify which branch you want to merge with.
10 See git-pull(1) for details
11 
12     git pull <remote> <branch>
13 
14 If you wish to set tracking information for this branch you can do so with:
15 
16     git branch --set-upstream dev origin/<branch>

git pull也失敗了，原因是沒有指定本地dev分支與遠程origin/dev分支的鏈接，根據提示，設置dev和origin/dev的鏈接：

1 $ git branch --set-upstream dev origin/dev
2 Branch dev set up to track remote branch dev from origin.

再pull：

1 $ git pull
2 Auto-merging hello.py
3 CONFLICT (content): Merge conflict in hello.py
4 Automatic merge failed; fix conflicts and then commit the result.

這回git pull成功，但是合並有沖突，需要手動解決，解決的方法和分支管理中的解決沖突完全一樣。解決後，提交，再push：

 1 $ git commit -m "merge & fix hello.py"
 2 [dev adca45d] merge & fix hello.py
 3 $ git push origin dev
 4 Counting objects: 10, done.
 5 Delta compression using up to 4 threads.
 6 Compressing objects: 100% (5/5), done.
 7 Writing objects: 100% (6/6), 747 bytes, done.
 8 Total 6 (delta 0), reused 0 (delta 0)
 9 To [email protected]:michaelliao/learngit.git
10    291bea8..adca45d  dev -> dev

因此，多人協作的工作模式通常是這樣：

1. 首先，可以試圖用git push origin branch-name推送自己的修改；

2. 如果推送失敗，則因為遠程分支比你的本地更新，需要先用git pull試圖合並；

3. 如果合並有沖突，則解決沖突，並在本地提交；

4. 沒有沖突或者解決掉沖突後，再用git push origin branch-name推送就能成功！

如果git pull提示“no tracking information”，則說明本地分支和遠程分支的鏈接關系沒有創建，用命令git branch --set-upstream branch-name origin/branch-name。

這就是多人協作的工作模式，一旦熟悉了，就非常簡單。

• 查看遠程庫信息，使用git remote -v；

• 本地新建的分支如果不推送到遠程，對其他人就是不可見的；

• 從本地推送分支，使用git push origin branch-name，如果推送失敗，先用git pull抓取遠程的新提交；

• 在本地創建和遠程分支對應的分支，使用git checkout -b branch-name origin/branch-name，本地和遠程分支的名稱最好一致；

• 建立本地分支和遠程分支的關聯，使用git branch --set-upstream branch-name origin/branch-name；

• 從遠程抓取分支，使用git pull，如果有沖突，要先處理沖突。

4、git分支管理