已经无法合并还报请合并git_GIT 分支管理:创建与合并分支、解决合并冲突
分支就是科幻電影里面的平行宇宙,當(dāng)你正在電腦前努力學(xué)習(xí)Git的時(shí)候,另一個(gè)你正在另一個(gè)平行宇宙里努力學(xué)習(xí)SVN。
如果兩個(gè)平行宇宙互不干擾,那對(duì)現(xiàn)在的你也沒啥影響。不過,在某個(gè)時(shí)間點(diǎn),兩個(gè)平行宇宙合并了,結(jié)果,你既學(xué)會(huì)了Git又學(xué)會(huì)了SVN!
分支在實(shí)際中有什么用呢?假設(shè)你準(zhǔn)備開發(fā)一個(gè)新功能,但是需要兩周才能完成,第一周你寫了50%的代碼,如果立刻提交,由于代碼還沒寫完,不完整的代碼庫(kù)會(huì)導(dǎo)致別人不能干活了。如果等代碼全部寫完再一次提交,又存在丟失每天進(jìn)度的巨大風(fēng)險(xiǎn)。
現(xiàn)在有了分支,就不用怕了。你創(chuàng)建了一個(gè)屬于你自己的分支,別人看不到,還繼續(xù)在原來的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到開發(fā)完畢后,再一次性合并到原來的分支上,這樣,既安全,又不影響別人工作。
其他版本控制系統(tǒng)如SVN等都有分支管理,但是用過之后你會(huì)發(fā)現(xiàn),這些版本控制系統(tǒng)創(chuàng)建和切換分支比蝸牛還慢,簡(jiǎn)直讓人無法忍受,結(jié)果分支功能成了擺設(shè),大家都不去用。
但Git的分支是與眾不同的,無論創(chuàng)建、切換和刪除分支,Git在1秒鐘之內(nèi)就能完成!無論你的版本庫(kù)是1個(gè)文件還是1萬(wàn)個(gè)文件。
創(chuàng)建與合并分支
在版本回退里,你已經(jīng)知道,每次提交,Git都把它們串成一條時(shí)間線,這條時(shí)間線就是一個(gè)分支。截止到目前,只有一條時(shí)間線,在Git里,這個(gè)分支叫主分支,即master分支。HEAD嚴(yán)格來說不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是當(dāng)前分支。
一開始的時(shí)候,master分支是一條線,Git用master指向最新的提交,再用HEAD指向master,就能確定當(dāng)前分支,以及當(dāng)前分支的提交點(diǎn):
每次提交,master分支都會(huì)向前移動(dòng)一步,這樣,隨著你不斷提交,master分支的線也越來越長(zhǎng):
當(dāng)我們創(chuàng)建新的分支,例如dev時(shí),Git新建了一個(gè)指針叫dev,指向master相同的提交,再把HEAD指向dev,就表示當(dāng)前分支在dev上:
你看,Git創(chuàng)建一個(gè)分支很快,因?yàn)槌嗽黾右粋€(gè)dev指針,改改HEAD的指向,工作區(qū)的文件都沒有任何變化!
不過,從現(xiàn)在開始,對(duì)工作區(qū)的修改和提交就是針對(duì)dev分支了,比如新提交一次后,dev指針往前移動(dòng)一步,而master指針不變:
假如我們?cè)赿ev上的工作完成了,就可以把dev合并到master上。Git怎么合并呢?最簡(jiǎn)單的方法,就是直接把master指向dev的當(dāng)前提交,就完成了合并:
所以Git合并分支也很快!就改改指針,工作區(qū)內(nèi)容也不變!
合并完分支后,甚至可以刪除dev分支。刪除dev分支就是把dev指針給刪掉,刪掉后,我們就剩下了一條master分支:
真是太神奇了,你看得出來有些提交是通過分支完成的嗎?
下面開始實(shí)戰(zhàn)。
首先,我們創(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è)修改,加上一行:
create new branch dev..
然后提交:
$ git add readme.txt
$ git commit-m "create new branch...."[dev 45ae9a9] create new branch....1 file changed, 1 insertion(+)
現(xiàn)在,dev分支的工作完成,我們就可以切換回master分支:
$ git checkout master
Switched to branch'master'Your branch is up-to-date with 'origin/master'.
切換回master分支后,再查看一個(gè)readme.txt文件,剛才添加的內(nèi)容不見了!因?yàn)槟莻€(gè)提交是在dev分支上,而master分支此刻的提交點(diǎn)并沒有變:
現(xiàn)在,我們把dev分支的工作成果合并到master分支上:
$ git merge dev
Updating 90bc1f7..45ae9a9
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 dev
Deleted branch dev (was 45ae9a9).
刪除后,查看branch,就只剩下master分支了:
$ git branch* master
因?yàn)閯?chuàng)建、合并和刪除分支非???#xff0c;所以Git鼓勵(lì)你使用分支完成某個(gè)任務(wù),合并后再刪掉分支,這和直接在master分支上工作效果是一樣的,但過程更安全。
小結(jié)
Git鼓勵(lì)大量使用分支:
查看分支:git branch
創(chuàng)建分支:git branch
切換分支:git checkout
創(chuàng)建+切換分支:git checkout -b
合并某分支到當(dāng)前分支:git merge
刪除分支:git branch -d
解決沖突
人生不如意之事十之八九,合并分支往往也不是一帆風(fēng)順的。
準(zhǔn)備新的feature1分支,繼續(xù)我們的新分支開發(fā):
$ git checkout -b feature1
Switched to a new branch'feature1'
修改readme.txt最后一行,改為:
create new branch feature1..
在feature1分支上提交:
$ git add readme.txt
$ git commit-m "create new branch feature1 first modify"[feature1 b4309b0] create new branch feature1 first modify1 file changed, 1 insertion(+)
切換到master分支:
$ git checkout master
Switched to branch'master'Your branch is ahead of'origin/master' by 1commit.
(use"git push" to publish your local commits)
Git還會(huì)自動(dòng)提示我們當(dāng)前master分支比遠(yuǎn)程的master分支要超前1個(gè)提交。
在master分支上把readme.txt文件的最后一行改為:
goback master....
提交:
$ git add readme.txt
$ git commit-m "goback master first modify"[master 0b56936] goback master first modify1 file changed, 1 insertion(+)
現(xiàn)在,master分支和feature1分支各自都分別有新的提交,變成了這樣:
這種情況下,Git無法執(zhí)行“快速合并”,只能試圖把各自的修改合并起來,但這種合并就可能會(huì)有沖突,我們?cè)囋嚳?#xff1a;
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflictinreadme.txt
Automatic merge failed; fix conflicts andthen commit the result.
果然沖突了!Git告訴我們,readme.txt文件存在沖突,必須手動(dòng)解決沖突后再提交。git status也可以告訴我們沖突的文件:
$ git status
On branch master
Your branch is ahead of'origin/master' by 2commits.
(use"git push"to publish your local commits)
You have unmerged paths.
(fix conflicts and run"git commit")
Unmerged paths:
(use"git add ..."to mark resolution)
both modified: readme.txt
no changes added to commit (use"git add" and/or "git commit -a")
我們可以直接查看readme.txt的內(nèi)容:
test git modify second
study git
three add
four add modify
five add modify
six add modify
seven add modify
eight add modify ...
create new branch dev..<<<<<<
goback master....=======create new branch feature1..>>>>>>> feature1
Git用<<<<<<>>>>>>標(biāo)記出不同分支的內(nèi)容,我們修改如下后保存:
test git modify second
study git
three add
four add modify
five add modify
six add modify
seven add modify
eight add modify ...
create new branch dev..
create new branch feature1..
goback master....
再提交:
$ git add readme.txt
$ git commit-m "fixed conflicts"[master 0f3d64a] fixed conflicts
現(xiàn)在,master分支和feature1分支變成了下圖所示:
用帶參數(shù)的git log也可以看到分支的合并情況:
$ git log --graph --pretty=oneline --abbrev-commit*0f3d64a fixed conflicts|\| *b4309b0 create new branch feature1 first modify* |0b56936 goback master first modify|/
*45ae9a9 create new branch....*90bc1f7 test name*c1bdf43 test commit*dd34c9a no add but commit,because use other parameter*4ed30d1 eight modify dify*b45ca96 eight modify*9332d40 seven modify*72c6f9b six modify*f64b5a0 five modify*de8fd65 four modify*83a4b1e three modify*01c05cf two modify*1acafa7 first modify* 09c1bba first git
最后,刪除feature1分支:
$ git branch -d feature1
Deleted branch feature1 (was b4309b0).
小結(jié)
當(dāng)Git無法自動(dòng)合并分支時(shí),就必須首先解決沖突。解決沖突后,再提交,合并完成。
用git log --graph命令可以看到分支合并圖。
總結(jié)
以上是生活随笔為你收集整理的已经无法合并还报请合并git_GIT 分支管理:创建与合并分支、解决合并冲突的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: hutool中的threadutil_H
- 下一篇: vue中页面跳转传值_vue的页面跳转方