創(chuàng)建合并分支

在 Git 中，每次提交毛仪，Git 都會(huì)把他們串成一條時(shí)間線段搁嗓，這個(gè)時(shí)間線就是分支。如下圖箱靴，目前只有一條時(shí)間線腺逛，在 Git 里面這個(gè)分支就是主分支，即master分支刨晴。HEAD嚴(yán)格來(lái)說(shuō)不是指向提交屉来，而是指向master，master才是指向提交的狈癞，所以茄靠，HEAD指向的就是當(dāng)前分支。

一開始的時(shí)候蝶桶，master分支是一條線慨绳，Git用master 指向最新的提交，再用HEAD指向master真竖，就能確定當(dāng)前分支脐雪，以及當(dāng)前分支的提交點(diǎn)：

image.png

每次提交，master分支都會(huì)向前移動(dòng)一步恢共，這樣战秋，隨著你不斷提交，master分支的線也越來(lái)越長(zhǎng)：

當(dāng)我們創(chuàng)建新的分支讨韭，例如dev時(shí)脂信，Git新建了一個(gè)指針叫dev，指向master相同的提交透硝，再把HEAD指向dev狰闪，就表示當(dāng)前分支在dev上：

image.png

在Git 上創(chuàng)建一個(gè)分支很快，因?yàn)橹皇窃黾恿艘粋€(gè) dev指針濒生，更新HEAD的指向埋泵，工作區(qū)沒有任何變化。
不過(guò)從現(xiàn)在開始罪治，對(duì)工作區(qū)的修改和提交就是針對(duì)dev分支了丽声，比如新提交一次后，dev指針往前移動(dòng)一步觉义，而master指針不變恒序。

image.png

當(dāng)我們?cè)赿ev 上的工作完成了，就可以把dev合并到master上谁撼。Git怎么合并呢歧胁？最簡(jiǎn)單的方法滋饲，就是直接把master指向dev的當(dāng)前提交，就完成了合并：

image.png

所以Git合并分支也很快喊巍！就改改指針屠缭，工作區(qū)內(nèi)容也不變！

合并完分支后崭参，甚至可以刪除dev分支呵曹。刪除dev分支就是把dev指針給刪掉，刪掉后何暮，我們就剩下了一條master分支：

image.png

下面開始練習(xí)一下：
首先奄喂，我們創(chuàng)建dev分支，然后切換到dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'

git checkout 命令加上-b參數(shù)表示創(chuàng)建并切換海洼，相當(dāng)于以下兩條命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

然后跨新，用git branch命令查看當(dāng)前分支：

$ git branch
* dev master

git branch命令會(huì)列出所有分支，當(dāng)前分支前面會(huì)標(biāo)一個(gè)*號(hào)坏逢。
然后域帐，我們就可以在dev分支上正常提交，比如對(duì)readme.txt做個(gè)修改是整，加上一行：Creating a new branch is quick.

然后提交：

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

現(xiàn)在肖揣，dev分支的工作完成，我們就可以切換回master分支：

$ git checkout master
Switched to branch 'master'

切換回master分支后浮入，再查看一個(gè)readme.txt文件龙优，剛才添加的內(nèi)容不見了！因?yàn)槟莻€(gè)提交是在dev分支上事秀，而master分支此刻的提交點(diǎn)并沒有變：

git-br-on-master

現(xiàn)在陋率，我們把dev分支的工作成果合并到master分支上：

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

git merge 命令用于合并指定分支到當(dāng)前分支。合并后秽晚，再查看readme.txt的內(nèi)容，就可以看到筒愚，和dev
分支的最新提交是完全一樣的赴蝇。注意到上面的Fast-forward信息，Git告訴我們巢掺，這次合并是“快進(jìn)模式”句伶，也就是直接把master指向dev的當(dāng)前提交，所以合并速度非陈降恚快考余。

當(dāng)然，也不是每次合并都能Fast-forward轧苫，我們后面會(huì)講其他方式的合并楚堤。
合并完成后，就可以放心地刪除dev分支了：

$ git branch -d devDeleted branch dev (was fec145a).

刪除后，查看branch身冬，就只剩下master分支了：

$ git branch
* master

因?yàn)閯?chuàng)建衅胀、合并和刪除分支非常快酥筝，所以Git鼓勵(lì)你使用分支完成某個(gè)任務(wù)滚躯，合并后再刪掉分支，這和直接在master
分支上工作效果是一樣的嘿歌，但過(guò)程更安全掸掏。

小結(jié)

Git鼓勵(lì)大量使用分支：

• 查看分支：git branch
• 創(chuàng)建分支：git branch <name>
• 切換分支：git checkout <name>
• 創(chuàng)建+切換分支：git checkout -b <name>
• 合并某分支到當(dāng)前分支：git merge <name>
• 刪除分支：git branch -d <name>

解決沖突

合并分支往往有可能出現(xiàn)沖突

準(zhǔn)備新的feature1分支，繼續(xù)我們的新分支開發(fā)：

$ git checkout -b feature1
Switched to a new branch 'feature1'

修改readme.txt最后一行宙帝，改為：Creating a new branch is quick AND simple.

在feature1分支上提交：

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

切換到master分支：

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

Git提示我們當(dāng)前master分支比遠(yuǎn)程的master分支要超前1個(gè)提交丧凤。

在master分支上把readme.txt文件的最后一行改為：Creating a new branch is quick & simple.

提交：

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

現(xiàn)在，master分支和feature1分支各自都分別有新的提交茄唐，變成了這樣：

git-br-feature1

這種情況下息裸，Git無(wú)法執(zhí)行“快速合并”，只能試圖把各自的修改合并起來(lái)沪编，但這種合并就可能會(huì)有沖突呼盆，我們?cè)囋嚳矗?/p>

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

Git提示，readme.txt文件存在沖突蚁廓，必須手動(dòng)解決沖突后再提交访圃。git status也可以告訴我們沖突的文件：

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

我們可以直接查看readme.txt的內(nèi)容：

<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

Git用<<<<<<<，=======相嵌，>>>>>>>

標(biāo)記出不同分支的內(nèi)容腿时，我們修改如下后保存：Creating a new branch is quick and simple.

再提交：

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

現(xiàn)在，master分支和feature1分支變成了下圖所示：

git-br-conflict-merged

用帶參數(shù)的git log也可以看到分支的合并情況：

$ git log --graph --pretty=oneline --abbrev-commit
*   59bc1cb conflict fixed
|\
| * 75a857c AND simple
* | 400b400 & simple
|/
* fec145a branch test
...

最后饭宾，刪除feature1分支：

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

工作完成批糟。

小結(jié)

當(dāng)Git無(wú)法自動(dòng)合并分支時(shí)，就必須首先解決沖突看铆。解決沖突后徽鼎，再提交，合并完成弹惦。
用git log --graph命令可以看到分支合并圖否淤。

分支管理策略

通常，合并分支時(shí)棠隐，如果可能石抡，Git會(huì)用Fast forward 模式，但這種模式下助泽，刪除分支后啰扛，會(huì)丟掉分支信息嚎京。
如果要強(qiáng)制禁用Fast forward 模式，Git就會(huì)在merge時(shí)生成一個(gè)新的commit侠讯，這樣挖藏，從分支歷史上就可以看出分支信息。

下面我們使用一下--no-ff方式的git merge：
首先厢漩，仍然創(chuàng)建并切換dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'

修改readme.txt文件膜眠，并提交一個(gè)新的commit：

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

現(xiàn)在，我們切換回master：

$ git checkout master
Switched to branch 'master'

準(zhǔn)備合并dev分支溜嗜，請(qǐng)注意--no-ff參數(shù)宵膨，表示禁用Fast forward：

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

因?yàn)楸敬魏喜⒁獎(jiǎng)?chuàng)建一個(gè)新的commit，所以加上-m參數(shù)炸宵，把commit描述寫進(jìn)去辟躏。
合并后，我們用git log看看分支歷史：

$ git log --graph --pretty=oneline --abbrev-commit
*   7825a50 merge with no-ff
|\
| * 6224937 add merge
|/
*   59bc1cb conflict fixed
...

可以看到土全，不使用Fast forward模式捎琐，merge后就像這樣：

git-no-ff-mode

分支策略

在實(shí)際開發(fā)中，我們應(yīng)該按照幾個(gè)基本原則進(jìn)行分支管理：

首先裹匙，master分支應(yīng)該是非常穩(wěn)定的瑞凑，也就是僅用來(lái)發(fā)布新版本，平時(shí)不能在上面干活概页；
那在哪干活呢籽御？干活都在dev分支上，也就是說(shuō)惰匙，dev分支是不穩(wěn)定的技掏，到某個(gè)時(shí)候，比如1.0版本發(fā)布時(shí)项鬼，再把dev分支合并到master上哑梳，在master分支發(fā)布1.0版本；
你和你的小伙伴們每個(gè)人都在dev分支上干活绘盟，每個(gè)人都有自己的分支鸠真，時(shí)不時(shí)地往dev分支上合并就可以了。

所以奥此，團(tuán)隊(duì)合作的分支看起來(lái)就像這樣：

git-br-policy

小結(jié)

Git分支十分強(qiáng)大，在團(tuán)隊(duì)開發(fā)中應(yīng)該充分應(yīng)用雁比。
合并分支時(shí)稚虎，加上--no-ff參數(shù)就可以用普通模式合并，合并后的歷史有分支偎捎，能看出來(lái)曾經(jīng)做過(guò)合并蠢终，而fast forward合并就看不出來(lái)曾經(jīng)做過(guò)合并序攘。

Bug分支

軟件開發(fā)中，bug就像家常便飯一樣寻拂。有了bug就需要修復(fù).
在Git中,每個(gè)bug都可以通過(guò)一個(gè)新的臨時(shí)分支來(lái)修復(fù)程奠，修復(fù)后，合并分支祭钉，然后將臨時(shí)分支刪除瞄沙。

當(dāng)你接到一個(gè)修復(fù)一個(gè)代號(hào)101的bug的任務(wù)時(shí)，很自然地慌核，你想創(chuàng)建一個(gè)分支issue-101來(lái)修復(fù)它距境，但是，等等垮卓，當(dāng)前正在dev上進(jìn)行的工作還沒有提交：

$ git status
# On branch dev
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   hello.py
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   readme.txt
#

并不是你不想提交垫桂，而是工作只進(jìn)行到一半，還沒法提交粟按，預(yù)計(jì)完成還需1天時(shí)間诬滩。但是，必須在兩個(gè)小時(shí)內(nèi)修復(fù)該bug灭将，怎么辦疼鸟？

Git還提供了一個(gè)stash功能，可以把當(dāng)前工作現(xiàn)場(chǎng)“儲(chǔ)藏”起來(lái)宗侦，等以后恢復(fù)現(xiàn)場(chǎng)后繼續(xù)工作：

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

現(xiàn)在愚臀，用git status查看工作區(qū)，就是干凈的（除非有沒有被Git管理的文件）矾利，因此可以放心地創(chuàng)建分支來(lái)修復(fù)bug姑裂。

首先確定要在哪個(gè)分支上修復(fù)bug，假定需要在master分支上修復(fù)男旗，就從master創(chuàng)建臨時(shí)分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
$ git checkout -b issue-101
Switched to a new branch 'issue-101'

現(xiàn)在修復(fù)bug舶斧，需要把“Git is free software ...”改為“Git is a free software ...”，然后提交：

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

修復(fù)完成后察皇，切換到master分支茴厉，并完成合并，最后刪除issue-101分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.

$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git branch -d issue-101
Deleted branch issue-101 (was cc17032).

bug修復(fù)完成什荣！現(xiàn)在矾缓，是時(shí)候接著回到dev分支干活了！

$ git checkout dev
Switched to branch 'dev'

$ git status
# On branch dev
nothing to commit (working directory clean)

工作區(qū)是干凈的稻爬，剛才的工作現(xiàn)場(chǎng)存到哪去了嗜闻？用git stash list命令看看：

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

工作現(xiàn)場(chǎng)還在，Git把stash內(nèi)容存在某個(gè)地方了桅锄，但是需要恢復(fù)一下琉雳，有兩個(gè)辦法：
一是用git stash apply恢復(fù)样眠，但是恢復(fù)后，stash內(nèi)容并不刪除翠肘，你需要用git stash drop來(lái)刪除檐束；
另一種方式是用git stash pop，恢復(fù)的同時(shí)把stash內(nèi)容也刪了：

$ git stash pop
# On branch dev
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   hello.py
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   readme.txt
#
Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

再用git stash list查看束倍，就看不到任何stash內(nèi)容了：

$ git stash list

你可以多次stash被丧，恢復(fù)的時(shí)候，先用git stash list查看肌幽，然后恢復(fù)指定的stash晚碾，用命令：

$ git stash apply stash@{0}

小結(jié)

修復(fù)bug時(shí)，我們會(huì)通過(guò)創(chuàng)建新的bug分支進(jìn)行修復(fù)喂急，然后合并格嘁，最后刪除；
當(dāng)手頭工作沒有完成時(shí)廊移，先把工作現(xiàn)場(chǎng) git stash一下糕簿，然后去修復(fù)bug，修復(fù)后狡孔，再git stash pop懂诗，回到工作現(xiàn)場(chǎng)。

Feature分支

軟件開發(fā)中苗膝，總有無(wú)窮無(wú)盡的新的功能要不斷添加進(jìn)來(lái)殃恒。
添加一個(gè)新功能時(shí)，你肯定不希望因?yàn)橐恍?shí)驗(yàn)性質(zhì)的代碼辱揭，把主分支搞亂了离唐，所以，每添加一個(gè)新功能问窃，最好新建一個(gè)feature分支亥鬓，在上面開發(fā)，完成后域庇，合并嵌戈，最后，刪除該feature分支听皿。

現(xiàn)在熟呛，你終于接到了一個(gè)新任務(wù)：開發(fā)代號(hào)為Vulcan的新功能，該功能計(jì)劃用于下一代星際飛船尉姨。
于是準(zhǔn)備開發(fā)：

$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan'

5分鐘后庵朝，開發(fā)完畢：

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

切回dev，準(zhǔn)備合并：

$ git checkout dev

一切順利的話，feature分支和bug分支是類似的偿短，合并，然后刪除馋没。
但是昔逗，就在此時(shí)，接到上級(jí)命令篷朵，因經(jīng)費(fèi)不足勾怒，新功能必須取消！
雖然白干了声旺，但是這個(gè)分支還是必須就地銷毀：

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

銷毀失敗笔链。Git友情提醒，feature-vulcan分支還沒有被合并腮猖，如果刪除鉴扫，將丟失掉修改，如果要強(qiáng)行刪除澈缺，需要使用命令git branch -D feature-vulcan坪创。
現(xiàn)在我們強(qiáng)行刪除：

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

終于刪除成功！

小結(jié)

開發(fā)一個(gè)新feature姐赡，最好新建一個(gè)分支莱预；
如果要丟棄一個(gè)沒有被合并過(guò)的分支，可以通過(guò)git branch -D <name>強(qiáng)行刪除项滑。

多人協(xié)作

當(dāng)你從遠(yuǎn)程倉(cāng)庫(kù)克隆時(shí)依沮，實(shí)際上Git自動(dòng)把本地的master分支和遠(yuǎn)程的master分支對(duì)應(yīng)起來(lái)了，并且枪狂，遠(yuǎn)程倉(cāng)庫(kù)的默認(rèn)名稱是origin危喉。

要查看遠(yuǎn)程庫(kù)的信息

要查看遠(yuǎn)程庫(kù)的信息，用 git remote：

$ git remote
origin

或者摘完，用git remote -v 顯示更詳細(xì)的信息：

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

上面顯示了可以抓取和推送的origin的地址姥饰。如果沒有推送權(quán)限，就看不到push的地址孝治。

推送分支

推送分支列粪，就是把該分支上的所有本地提交推送到遠(yuǎn)程庫(kù)。
推送時(shí)谈飒，要指定本地分支岂座，這樣，Git就會(huì)把該分支推送到遠(yuǎn)程庫(kù)對(duì)應(yīng)的遠(yuǎn)程分支上：

$ git push origin master

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

$ git push origin dev

但是，并不是一定要把本地分支往遠(yuǎn)程推送手素，那么鸳址，哪些分支需要推送瘩蚪，哪些不需要呢？

master分支是主分支稿黍，因此要時(shí)刻與遠(yuǎn)程同步疹瘦；

dev分支是開發(fā)分支，團(tuán)隊(duì)所有成員都需要在上面工作巡球，所以也需要與遠(yuǎn)程同步言沐；

bug分支只用于在本地修復(fù)bug，就沒必要推到遠(yuǎn)程了酣栈，除非老板要看看你每周到底修復(fù)了幾個(gè)bug险胰；

feature分支是否推到遠(yuǎn)程，取決于你是否和你的小伙伴合作在上面開發(fā)矿筝。

抓取分支

多人協(xié)作時(shí)起便，大家都會(huì)往master和dev分支上推送各自的修改。

現(xiàn)在窖维，模擬一個(gè)你的小伙伴缨睡，可以在另一臺(tái)電腦（注意要把SSH Key添加到GitHub）或者同一臺(tái)電腦的另一個(gè)目錄下克隆：

$ git clone git@github.com:XXX/learngit.git
Cloning into 'learngit'...
remote: Counting objects: 46, done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 46 (delta 16), reused 45 (delta 15)
Receiving objects: 100% (46/46), 15.69 KiB | 6 KiB/s, done.
Resolving deltas: 100% (16/16), done.

當(dāng)你的小伙伴從遠(yuǎn)程庫(kù)clone時(shí)陈辱，默認(rèn)情況下奖年，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：

$ git branch
* master

現(xiàn)在沛贪，你的小伙伴要在dev分支上開發(fā)陋守，就必須創(chuàng)建遠(yuǎn)程origin的dev分支到本地，于是他用這個(gè)命令創(chuàng)建本地dev分支：

$ git checkout -b dev origin/dev

現(xiàn)在利赋，他就可以在dev上繼續(xù)修改水评，然后，時(shí)不時(shí)地把dev分支push到遠(yuǎn)程：

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

你的小伙伴已經(jīng)向origin/dev分支推送了他的提交媚送，而碰巧你也對(duì)同樣的文件作了修改中燥，并試圖推送：

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

推送失敗，因?yàn)槟愕男』锇榈淖钚绿峤缓湍阍噲D推送的提交有沖突塘偎，解決辦法也很簡(jiǎn)單疗涉，Git已經(jīng)提示我們，先用 git pull 把最新的提交從origin/dev 抓下來(lái)吟秩，然后咱扣，在本地合并，解決沖突涵防，再推送：

$ git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From github.com:michaelliao/learngit
   fc38031..291bea8  dev        -> origin/dev
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream dev origin/<branch>

git pull 也失敗了闹伪，原因是沒有指定本地dev分支與遠(yuǎn)程origin/dev分支的鏈接，根據(jù)提示，設(shè)置dev
和origin/dev的鏈接：

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

再pull：

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

這回git pull
成功偏瓤，但是合并有沖突杀怠，需要手動(dòng)解決，解決的方法和分支管理中的解決沖突

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

因此厅克，多人協(xié)作的工作模式通常是這樣：

首先驮肉，可以試圖用git push origin branch-name推送自己的修改；
如果推送失敗已骇，則因?yàn)檫h(yuǎn)程分支比你的本地更新，需要先用git pull試圖合并票编；
如果合并有沖突褪储，則解決沖突，并在本地提交慧域；
沒有沖突或者解決掉沖突后鲤竹，再用git push origin branch-name
推送就能成功！

如果git pull
提示“no tracking information”昔榴，則說(shuō)明本地分支和遠(yuǎn)程分支的鏈接關(guān)系沒有創(chuàng)建辛藻，用命令git branch --set-upstream branch-name origin/branch-name。
這就是多人協(xié)作的工作模式互订，一旦熟悉了吱肌，就非常簡(jiǎn)單。

小結(jié)

• 查看遠(yuǎn)程庫(kù)信息仰禽，使用git remote -v
• 本地新建的分支如果不推送到遠(yuǎn)程氮墨，對(duì)其他人就是不可見的
• 從本地推送分支，使用git push origin branch-name吐葵，如果推送失敗规揪，先用git pull
  抓取遠(yuǎn)程的新提交
• 在本地創(chuàng)建和遠(yuǎn)程分支對(duì)應(yīng)的分支，使用git checkout -b branch-name origin/branch-name温峭，本地和遠(yuǎn)程分支的名稱最好一致
• 建立本地分支和遠(yuǎn)程分支的關(guān)聯(lián)猛铅，使用git branch --set-upstream branch-name origin/branch-name
• 從遠(yuǎn)程抓取分支，使用git pull凤藏，如果有沖突奸忽，要先處理沖突。

參考

• 廖雪峰的官方網(wǎng)站
• CodeSchool
• Git 狀態(tài)轉(zhuǎn)換圖