git 为什么会有多个head_继续学习Git
遠程倉庫
Git是分布式版本控制系統，同一個Git倉庫，可以分布到不同的機器上。怎么分布呢？最早，肯定只有一臺機器有一個原始版本庫，此后，別的機器可以“克隆”這個原始版本庫，而且每臺機器的版本庫其實都是一樣的，并沒有主次之分
其實一臺電腦上也是可以克隆多個版本庫的，只要不在同一個目錄下。不過，現實生活中是不會有人這么傻的在一臺電腦上搞幾個遠程庫玩，因為一臺電腦上搞幾個遠程庫完全沒有意義，而且硬盤掛了會導致所有庫都掛掉
實際情況往往是這樣，找一臺電腦充當服務器的角色，每天24小時開機，其他每個人都從這個“服務器”倉庫克隆一份到自己的電腦上，并且各自把各自的提交推送到服務器倉庫里，也從服務器倉庫中拉取別人的提交。
完全可以自己搭建一臺運行Git的服務器，不過現階段，為了學Git先搭個服務器絕對是小題大作。好在這個世界上有個叫GitHub的神奇的網站，從名字就可以看出，這個網站就是提供Git倉庫托管服務的，所以，只要注冊一個GitHub賬號，就可以免費獲得Git遠程倉庫。
在繼續閱讀后續內容前，請自行注冊GitHub賬號。由于你的本地Git倉庫和GitHub倉庫之間的傳輸是通過SSH加密的，所以，需要一點設置：
第1步：創建SSH Key。在用戶主目錄下，看看有沒有.ssh目錄，如果有，再看看這個目錄下有沒有id_rsa和id_rsa.pub這兩個文件，如果已經有了，可直接跳到下一步。如果沒有，打開Shell(Windows下打開Git Bash)，創建SSH Key：
$?ssh-keygen?-t?rsa?-C?"youremail@example.com"你需要把郵件地址換成你自己的郵件地址，然后一路回車，使用默認值即可，由于這個Key也不是用于軍事目的，所以也無需設置密碼。
如果一切順利的話，可以在用戶主目錄里找到.ssh目錄，里面有id_rsa和id_rsa.pub兩個文件，這兩個就是SSH Key的秘鑰對，id_rsa是私鑰，不能泄露出去，id_rsa.pub是公鑰，可以放心地告訴任何人。
第2步：登陸GitHub，打開“Account settings”，“SSH Keys”頁面：
然后，點“Add SSH Key”，填上任意Title，在Key文本框里粘貼id_rsa.pub文件的內容：
image-20201219235648004點“Add Key”，你就應該看到已經添加的Key：
image-20201219235711417為什么GitHub需要SSH Key呢？因為GitHub需要識別出你推送的提交確實是你推送的，而不是別人冒充的，而Git支持SSH協議，所以，GitHub只要知道了你的公鑰，就可以確認只有你自己才能推送。
當然，GitHub允許你添加多個Key。假定你有若干電腦，你一會兒在公司提交，一會兒在家里提交，只要把每臺電腦的Key都添加到GitHub，就可以在每臺電腦上往GitHub推送了。
最后友情提示，在GitHub上免費托管的Git倉庫，任何人都可以看到喔(但只有你自己才能改)。所以，不要把敏感信息放進去。
如果你不想讓別人看到Git庫，有兩個辦法，一個是交點保護費，讓GitHub把公開的倉庫變成私有的，這樣別人就看不見了(不可讀更不可寫)。另一個辦法是自己動手，搭一個Git服務器，因為是你自己的Git服務器，所以別人也是看不見的。這個方法我們后面會講到的，相當簡單，公司內部開發必備。
確保你擁有一個GitHub賬號后，我們就即將開始遠程倉庫的學習。
添加遠程庫
現在的情景是，你已經在本地創建了一個Git倉庫后，又想在GitHub創建一個Git倉庫，并且讓這兩個倉庫進行遠程同步，這樣，GitHub上的倉庫既可以作為備份，又可以讓其他人通過該倉庫來協作
在GitHub上創建一個遠程庫
登陸GitHub，然后，在右上角找到“Create a new repo”按鈕，創建一個新的倉庫：
image-20201219235728372關聯本地庫和遠程庫
目前，在GitHub上的這個learngit倉庫還是空的，GitHub告訴我們，可以從這個倉庫克隆出新的倉庫，也可以把一個已有的本地倉庫與之關聯，然后，把本地倉庫的內容推送到GitHub倉庫。
git?remote?add?origin?git@github.com:yourname/LearnMysql.gityourname替換成你自己的GitHub用戶名
添加后，遠程庫的名字就是origin，這是Git默認的叫法，也可以改成別的，但是origin這個名字一看就知道是遠程庫。
#查看當前遠程庫的名字
git?remote?-v?
#移除一個遠程庫
git?remote?remove?image-20201219235752166本地庫推到遠程庫
git?push?-u?origin?master把本地庫的內容推送到遠程，用git push命令，實際上是把當前分支master推送到遠程。
由于遠程庫是空的，我們第一次推送master分支時，加上了-u參數，Git不但會把本地的master分支內容推送的遠程新的master分支，還會把本地的master分支和遠程的master分支關聯起來，在以后的推送或者拉取時就可以簡化命令。
image-20201219235813561image-20201219235829996以后每次本地進行了修改，都可以推送到GitHub上
git?push?origin?master
從遠程庫克隆
克隆
git?clone?git@github.com:yourname/LearnMysql.git
image-20201219235847378
分支管理
分支就是科幻電影里面的平行宇宙，當你正在電腦前努力學習Git的時候，另一個你正在另一個平行宇宙里努力學習SVN。
如果兩個平行宇宙互不干擾，那對現在的你也沒啥影響。不過，在某個時間點，兩個平行宇宙合并了，結果，你既學會了Git又學會了SVN！
image-20201219235903302分支在實際中有什么用呢？假設你準備開發一個新功能，但是需要兩周才能完成，第一周你寫了50%的代碼，如果立刻提交，由于代碼還沒寫完，不完整的代碼庫會導致別人不能干活了。如果等代碼全部寫完再一次提交，又存在丟失每天進度的巨大風險。
現在有了分支，就不用怕了。你創建了一個屬于你自己的分支，別人看不到，還繼續在原來的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到開發完畢后，再一次性合并到原來的分支上，這樣，既安全，又不影響別人工作。
創建與合并分支
在版本回退里，你已經知道，每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，在Git里，這個分支叫主分支，即master分支。HEAD嚴格來說不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是當前分支。
原理
一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能確定當前分支，以及當前分支的提交點：
image-20201219235917777每次提交，master分支都會向前移動一步，這樣，隨著你不斷提交，master分支的線也越來越長。
當我們創建新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當前分支在dev上：
image-20201219235930729Git創建一個分支很快，因為除了增加一個dev指針，改改HEAD的指向，工作區的文件都沒有任何變化！
不過，從現在開始，對工作區的修改和提交就是針對dev分支了，比如新提交一次后，dev指針往前移動一步，而master指針不變：
image-20201219235946295假如我們在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最簡單的方法，就是直接把master指向dev的當前提交，就完成了合并：
image-20201220000000199合并完分支后，甚至可以刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉后，我們就剩下了一條master分支：
image-20201220000014348
實戰
- 首先，我們創建dev分支，然后切換到dev分支：
Switched?to?a?new?branch?'dev'
git checkout命令加上-b參數表示創建并切換，相當于以下兩條命令：
$?git?branch?dev$?git?checkout?dev
Switched?to?branch?'dev'
- 然后，用git branch命令查看當前分支：
*?dev
??master
git branch命令會列出所有分支，當前分支前面會標一個*號。
然后，我們就可以在dev分支上正常提交，比如對readme.txt做個修改，加上一行：
Creating a new branch is quick.然后提交：
$?git?add?readme.txt?$?git?commit?-m?"branch?test"
[dev?b17d20e]?branch?test
?1?file?changed,?1?insertion(+)
現在，dev分支的工作完成，我們就可以切換回master分支：
$?git?checkout?masterSwitched?to?branch?'master'
切換回master分支后，再查看一個readme.txt文件，剛才添加的內容不見了！因為那個提交是在dev分支上，而master分支此刻的提交點并沒有變：
image-20201220000035712- 現在，我們把dev分支的工作成果合并到master分支上：
Updating?d46f35e..b17d20e
Fast-forward
?readme.txt?|?1?+
?1?file?changed,?1?insertion(+)
git merge命令用于合并指定分支到當前分支。合并后，再查看readme.txt的內容，就可以看到，和dev分支的最新提交是完全一樣的。
注意到上面的Fast-forward信息，Git告訴我們，這次合并是“快進模式”，也就是直接把master指向dev的當前提交，所以合并速度非常快。
當然，也不是每次合并都能Fast-forward，我們后面會講其他方式的合并。
- 合并完成后，就可以放心地刪除dev分支了：
Deleted?branch?dev?(was?b17d20e).
刪除后，查看branch，就只剩下master分支了：
$?git?branch*?master
因為創建、合并和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合并后再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。
- switch
我們注意到切換分支使用git checkout，而前面講過的撤銷修改則是git checkout --，同一個命令，有兩種作用，確實有點令人迷惑。
實際上，切換分支這個動作，用switch更科學。因此，最新版本的Git提供了新的git switch命令來切換分支：
創建并切換到新的dev分支，可以使用：
$?git?switch?-c?dev直接切換到已有的master分支，可以使用：
$?git?switch?master使用新的git switch命令，比git checkout要更容易理解。
分支沖突
人生不如意之事十之八九，合并分支往往也不是一帆風順的。
- 準備新的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?14096d0]?AND?simple
?1?file?changed,?1?insertion(+),?1?deletion(-)
- 切換到master分支：
Switched?to?branch?'master'
Your?branch?is?ahead?of?'origin/master'?by?1?commit.
??(use?"git?push"?to?publish?your?local?commits)
Git還會自動提示我們當前master分支比遠程的master分支要超前1個提交。
在master分支上把readme.txt文件的最后一行改為：
Creating?a?new?branch?is?quick?&?simple.提交：
$?git?add?readme.txt?$?git?commit?-m?"&?simple"
[master?5dc6824]?&?simple
?1?file?changed,?1?insertion(+),?1?deletion(-)
現在，master分支和feature1分支各自都分別有新的提交，變成了這樣：
image-20201220000051703- 這種情況下，Git無法執行“快速合并”，只能試圖把各自的修改合并起來，但這種合并就可能會有沖突，我們試試看：
Auto-merging?readme.txt
CONFLICT?(content):?Merge?conflict?in?readme.txt
Automatic?merge?failed;?fix?conflicts?and?then?commit?the?result.
果然沖突了！Git告訴我們，readme.txt文件存在沖突，必須手動解決沖突后再提交。git status也可以告訴我們沖突的文件：
$?git?statusOn?branch?master
Your?branch?is?ahead?of?'origin/master'?by?2?commits.
??(use?"git?push"?to?publish?your?local?commits)
You?have?unmerged?paths.
??(fix?conflicts?and?run?"git?commit")
??(use?"git?merge?--abort"?to?abort?the?merge)
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的內容：
Git?is?a?distributed?version?control?system.Git?is?free?software?distributed?under?the?GPL.
Git?has?a?mutable?index?called?stage.
Git?tracks?changes?of?files.
<<<<<<Creating?a?new?branch?is?quick?&?simple.
=======
Creating?a?new?branch?is?quick?AND?simple.
>>>>>>>?feature1
Git用<<<<<<<，=======，>>>>>>>標記出不同分支的內容，我們修改如下后保存：
Creating?a?new?branch?is?quick?and?simple.再提交：
$?git?add?readme.txt?$?git?commit?-m?"conflict?fixed"
[master?cf810e4]?conflict?fixed
現在，master分支和feature1分支變成了下圖所示：
image-20201220000106934- 用帶參數的git log也可以看到分支的合并情況：
*???cf810e4?(HEAD?->?master)?conflict?fixed
|\??
|?*?14096d0?(feature1)?AND?simple
*?|?5dc6824?&?simple
|/??
*?b17d20e?branch?test
*?d46f35e?(origin/master)?remove?test.txt
*?b84166e?add?test.txt
*?519219b?git?tracks?changes
*?e43a48b?understand?how?stage?works
*?1094adb?append?GPL
*?e475afc?add?distributed
*?eaadf4e?wrote?a?readme?file
最后，刪除feature1分支：
$?git?branch?-d?feature1Deleted?branch?feature1?(was?14096d0).
分支管理策略
原理
通常，合并分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支后，會丟掉分支信息。
如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。
下面我們實戰一下--no-ff方式的git merge：
- 首先，仍然創建并切換dev分支：
Switched?to?a?new?branch?'dev'
修改readme.txt文件，并提交一個新的commit：
$?git?add?readme.txt?$?git?commit?-m?"add?merge"
[dev?f52c633]?add?merge
?1?file?changed,?1?insertion(+)
- 現在，我們切換回master：
Switched?to?branch?'master'
準備合并dev分支，請注意--no-ff參數，表示禁用Fast forward：
$?git?merge?--no-ff?-m?"merge?with?no-ff"?devMerge?made?by?the?'recursive'?strategy.
?readme.txt?|?1?+
?1?file?changed,?1?insertion(+)
- 因為本次合并要創建一個新的commit，所以加上-m參數，把commit描述寫進去。
合并后，我們用git log看看分支歷史：
$?git?log?--graph?--pretty=oneline?--abbrev-commit*???e1e9c68?(HEAD?->?master)?merge?with?no-ff
|\??
|?*?f52c633?(dev)?add?merge
|/??
*???cf810e4?conflict?fixed
...
可以看到，不使用Fast forward模式，merge后就像這樣：
image-20201220000124091實際開發中
首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發布時，再把dev分支合并到master上，在master分支發布1.0版本；
你和你的小伙伴們每個人都在dev分支上干活，每個人都有自己的分支，時不時地往dev分支上合并就可以了。
所以，團隊合作的分支看起來就像這樣：
image-20201220000136775Bug分支
軟件開發中，bug就像家常便飯一樣。有了bug就需要修復，在Git中，由于分支是如此的強大，所以，每個bug都可以通過一個新的臨時分支來修復，修復后，合并分支，然后將臨時分支刪除。
- 當你接到一個修復一個代號101的bug的任務時，很自然地，你想創建一個分支issue-101來修復它，但是，等等，當前正在dev上進行的工作還沒有提交：
On?branch?dev
Changes?to?be?committed:
??(use?"git?reset?HEAD?..."?to?unstage)
?new?file:???hello.py
Changes?not?staged?for?commit:
??(use?"git?add?..."?to?update?what?will?be?committed)
??(use?"git?checkout?--?..."?to?discard?changes?in?working?directory)
?modified:???readme.txt
并不是你不想提交，而是工作只進行到一半，還沒法提交，預計完成還需1天時間。但是，必須在兩個小時內修復該bug，怎么辦？
- 幸好，Git還提供了一個stash功能，可以把當前工作現場“儲藏”起來，等以后恢復現場后繼續工作：
Saved?working?directory?and?index?state?WIP?on?dev:?f52c633?add?merge
現在，用git status查看工作區，就是干凈的(除非有沒有被Git管理的文件)，因此可以放心地創建分支來修復bug。
- 首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master創建臨時分支：
Switched?to?branch?'master'
Your?branch?is?ahead?of?'origin/master'?by?6?commits.
??(use?"git?push"?to?publish?your?local?commits)
$?git?checkout?-b?issue-101
Switched?to?a?new?branch?'issue-101'
- 現在修復bug，需要把“Git is free software ...”改為“Git is a free software ...”，然后提交：
$?git?commit?-m?"fix?bug?101"
[issue-101?4c805e2]?fix?bug?101
?1?file?changed,?1?insertion(+),?1?deletion(-)
- 修復完成后，切換到master分支，并完成合并，最后刪除issue-101分支：
Switched?to?branch?'master'
Your?branch?is?ahead?of?'origin/master'?by?6?commits.
??(use?"git?push"?to?publish?your?local?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(-)
- 太棒了，原計劃兩個小時的bug修復只花了5分鐘！現在，是時候接著回到dev分支干活了！
Switched?to?branch?'dev'
$?git?status
On?branch?dev
nothing?to?commit,?working?tree?clean
- 工作區是干凈的，剛才的工作現場存到哪去了？用git stash list命令看看：
stash@{0}:?WIP?on?dev:?f52c633?add?merge
工作現場還在，Git把stash內容存在某個地方了，但是需要恢復一下，有兩個辦法：
一是用git stash apply恢復，但是恢復后，stash內容并不刪除，你需要用git stash drop來刪除；
另一種方式是用git stash pop，恢復的同時把stash內容也刪了：
On?branch?dev
Changes?to?be?committed:
??(use?"git?reset?HEAD?..."?to?unstage)
?new?file:???hello.py
Changes?not?staged?for?commit:
??(use?"git?add?..."?to?update?what?will?be?committed)
??(use?"git?checkout?--?..."?to?discard?changes?in?working?directory)
?modified:???readme.txt
Dropped?refs/stash@{0}?(5d677e2ee266f39ea296182fb2354265b91b3b2a)
再用git stash list查看，就看不到任何stash內容了：
$?git?stash?list你可以多次stash，恢復的時候，先用git stash list查看，然后恢復指定的stash，用命令：
$?git?stash?apply?stash@{0}- 在master分支上修復了bug后，我們要想一想，dev分支是早期從master分支分出來的，所以，這個bug其實在當前dev分支上也存在。
那怎么在dev分支上修復同樣的bug？重復操作一次，提交不就行了？
有木有更簡單的方法？
有！
同樣的bug，要在dev上修復，我們只需要把4c805e2 fix bug 101這個 ? ? ? ? 提交所做的修改“復制”到dev分支。注意：我們只想復制4c805e2 fix bug 101這個提交所做的修改，并不是把整個master分支merge過來。
為了方便操作，Git專門提供了一個cherry-pick命令，讓我們能復制一個特定的提交到當前分支：
*?dev
??master
$?git?cherry-pick?4c805e2
[master?1d4b803]?fix?bug?101
?1?file?changed,?1?insertion(+),?1?deletion(-)
Git自動給dev分支做了一次提交，注意這次提交的commit是1d4b803，它并不同于master的4c805e2，因為這兩個commit只是改動相同，但確實是兩個不同的commit。用git cherry-pick，我們就不需要在dev分支上手動再把修bug的過程重復一遍。
既然可以在master分支上修復bug后，在dev分支上可以“重放”這個修復過程，那么直接在dev分支上修復bug，然后在master分支上“重放”行不行？當然可以，不過你仍然需要git stash命令保存現場，才能從dev分支切換到master分支。
Feature分支
軟件開發中，總有無窮無盡的新的功能要不斷添加進來。
添加一個新功能時，你肯定不希望因為一些實驗性質的代碼，把主分支搞亂了，所以，每添加一個新功能，最好新建一個feature分支，在上面開發，完成后，合并，最后，刪除該feature分支。
現在，你終于接到了一個新任務：開發代號為Vulcan的新功能，該功能計劃用于下一代星際飛船。
- 于是準備開發：
Switched?to?a?new?branch?'feature-vulcan'
5分鐘后，開發完畢：
$?git?add?vulcan.py$?git?status
On?branch?feature-vulcan
Changes?to?be?committed:
??(use?"git?reset?HEAD?..."?to?unstage)
?new?file:???vulcan.py
$?git?commit?-m?"add?feature?vulcan"
[feature-vulcan?287773e]?add?feature?vulcan
?1?file?changed,?2?insertions(+)
?create?mode?100644?vulcan.py
切回dev，準備合并：
$?git?switch?dev一切順利的話，feature分支和bug分支是類似的，合并，然后刪除。
- 但是！
就在此時，接到上級命令，因經費不足，新功能必須取消！
雖然白干了，但是這個包含機密資料的分支還是必須就地銷毀：
$?git?branch?-d?feature-vulcanerror:?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分支還沒有被合并，如果刪除，將丟失掉修改，如果要強行刪除，需要使用大寫的-D參數。。
現在我們強行刪除：
$?git?branch?-D?feature-vulcanDeleted?branch?feature-vulcan?(was?287773e).
終于刪除成功！
多人協作
當你從遠程倉庫克隆時，實際上Git自動把本地的master分支和遠程的master分支對應起來了，并且，遠程倉庫的默認名稱是origin。
- 要查看遠程庫的信息，用git remote：
origin
- 或者，用git remote -v顯示更詳細的信息：
origin??git@github.com:michaelliao/learngit.git?(fetch)
origin??git@github.com:michaelliao/learngit.git?(push)
上面顯示了可以抓取和推送的origin的地址。如果沒有推送權限，就看不到push的地址。
推送分支
- 推送分支，就是把該分支上的所有本地提交推送到遠程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：
如果要推送其他分支，比如dev，就改成：
$?git?push?origin?dev- 但是，并不是一定要把本地分支往遠程推送，那么，哪些分支需要推送，哪些不需要呢？
- master分支是主分支，因此要時刻與遠程同步；
- dev分支是開發分支，團隊所有成員都需要在上面工作，所以也需要與遠程同步；
- bug分支只用于在本地修復bug，就沒必要推到遠程了，除非老板要看看你每周到底修復了幾個bug；
- feature分支是否推到遠程，取決于你是否和你的小伙伴合作在上面開發。
拉取分支
多人協作時，大家都會往master和dev分支上推送各自的修改。
- 現在，模擬一個你的小伙伴，可以在另一臺電腦(注意要把SSH Key添加到GitHub)或者同一臺電腦的另一個目錄下克隆：
Cloning?into?'learngit'...
remote:?Counting?objects:?40,?done.
remote:?Compressing?objects:?100%?(21/21),?done.
remote:?Total?40?(delta?14),?reused?40?(delta?14),?pack-reused?0
Receiving?objects:?100%?(40/40),?done.
Resolving?deltas:?100%?(14/14),?done.
當你的小伙伴從遠程庫clone時，默認情況下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：
$?git?branch*?master
- 現在，你的小伙伴要在dev分支上開發，就必須創建遠程origin的dev分支到本地，于是他用這個命令創建本地dev分支：
現在，他就可以在dev上繼續修改，然后，時不時地把dev分支push到遠程：
$?git?add?env.txt$?git?commit?-m?"add?env"
[dev?7a5e5dd]?add?env
?1?file?changed,?1?insertion(+)
?create?mode?100644?env.txt
$?git?push?origin?dev
Counting?objects:?3,?done.
Delta?compression?using?up?to?4?threads.
Compressing?objects:?100%?(2/2),?done.
Writing?objects:?100%?(3/3),?308?bytes?|?308.00?KiB/s,?done.
Total?3?(delta?0),?reused?0?(delta?0)
To?github.com:michaelliao/learngit.git
???f52c633..7a5e5dd??dev?->?dev
- 小伙伴已經向origin/dev分支推送了他的提交，而碰巧你也對同樣的文件作了修改，并試圖推送：
env
$?git?add?env.txt
$?git?commit?-m?"add?new?env"
[dev?7bd91f1]?add?new?env
?1?file?changed,?1?insertion(+)
?create?mode?100644?env.txt
$?git?push?origin?dev
To?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.?Integrate?the?remote?changes?(e.g.
hint:?'git?pull?...')?before?pushing?again.
hint:?See?the?'Note?about?fast-forwards'?in?'git?push?--help'?for?details.
- 推送失敗，因為你的小伙伴的最新提交和你試圖推送的提交有沖突，解決辦法也很簡單，Git已經提示我們，先用git pull把最新的提交從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??
If?you?wish?to?set?tracking?information?for?this?branch?you?can?do?so?with:
????git?branch?--set-upstream-to=origin/?dev
- git pull也失敗了，原因是沒有指定本地dev分支與遠程origin/dev分支的鏈接，根據提示，設置dev和origin/dev的鏈接：
Branch?'dev'?set?up?to?track?remote?branch?'dev'?from?'origin'.
再pull：
$?git?pullAuto-merging?env.txt
CONFLICT?(add/add):?Merge?conflict?in?env.txt
Automatic?merge?failed;?fix?conflicts?and?then?commit?the?result.
這回git pull成功，但是合并有沖突，需要手動解決，解決的方法和分支管理中的解決沖突完全一樣。解決后，提交，再push：
$?git?commit?-m?"fix?env?conflict"[dev?57c53ab]?fix?env?conflict
$?git?push?origin?dev
Counting?objects:?6,?done.
Delta?compression?using?up?to?4?threads.
Compressing?objects:?100%?(4/4),?done.
Writing?objects:?100%?(6/6),?621?bytes?|?621.00?KiB/s,?done.
Total?6?(delta?0),?reused?0?(delta?0)
To?github.com:michaelliao/learngit.git
???7a5e5dd..57c53ab??dev?->?dev
小結
因此，多人協作的工作模式通常是這樣：
如果git pull提示no tracking information，則說明本地分支和遠程分支的鏈接關系沒有創建，用命令git branch --set-upstream-to origin/。
這就是多人協作的工作模式，一旦熟悉了，就非常簡單。
Rebase
多人在同一個分支上協作時，很容易出現沖突。即使沒有沖突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。
- 每次合并再push后，分支變成了這樣：
*?d1be385?(HEAD?->?master,?origin/master)?init?hello
*???e5e69f1?Merge?branch?'dev'
|\??
|?*???57c53ab?(origin/dev,?dev)?fix?env?conflict
|?|\??
|?|?*?7a5e5dd?add?env
|?*?|?7bd91f1?add?new?env
|?|/??
*?|???12a631b?merged?bug?fix?101
|\?\??
|?*?|?4c805e2?fix?bug?101
|/?/??
*?|???e1e9c68?merge?with?no-ff
|\?\??
|?|/??
|?*?f52c633?add?merge
|/??
*???cf810e4?conflict?fixed
總之看上去很亂，有強迫癥的童鞋會問：為什么Git的提交歷史不能是一條干凈的直線？
- Git有一種稱為rebase的操作，有人把它翻譯成“變基”。
在和遠程分支同步后，我們對hello.py這個文件做了兩次提交。用git log命令看看：
$?git?log?--graph?--pretty=oneline?--abbrev-commit*?582d922?(HEAD?->?master)?add?author
*?8875536?add?comment
*?d1be385?(origin/master)?init?hello
*???e5e69f1?Merge?branch?'dev'
|\??
|?*???57c53ab?(origin/dev,?dev)?fix?env?conflict
|?|\??
|?|?*?7a5e5dd?add?env
|?*?|?7bd91f1?add?new?env
...
注意到Git用(HEAD -> master)和(origin/master)標識出當前分支的HEAD和遠程origin的位置分別是582d922 add author和d1be385 init hello，本地分支比遠程分支快兩個提交。
- 現在我們嘗試推送本地分支：
To?github.com:michaelliao/learngit.git
?!?[rejected]????????master?->?master?(fetch?first)
error:?failed?to?push?some?refs?to?'git@github.com:michaelliao/learngit.git'
hint:?Updates?were?rejected?because?the?remote?contains?work?that?you?do
hint:?not?have?locally.?This?is?usually?caused?by?another?repository?pushing
hint:?to?the?same?ref.?You?may?want?to?first?integrate?the?remote?changes
hint:?(e.g.,?'git?pull?...')?before?pushing?again.
hint:?See?the?'Note?about?fast-forwards'?in?'git?push?--help'?for?details.
- 很不幸，失敗了，這說明有人先于我們推送了遠程分支。按照經驗，先pull一下：
remote:?Counting?objects:?3,?done.
remote:?Compressing?objects:?100%?(1/1),?done.
remote:?Total?3?(delta?1),?reused?3?(delta?1),?pack-reused?0
Unpacking?objects:?100%?(3/3),?done.
From?github.com:michaelliao/learngit
???d1be385..f005ed4??master?????->?origin/master
?*?[new?tag]?????????v1.0???????->?v1.0
Auto-merging?hello.py
Merge?made?by?the?'recursive'?strategy.
?hello.py?|?1?+
?1?file?changed,?1?insertion(+)
- 再用git status看看狀態：
On?branch?master
Your?branch?is?ahead?of?'origin/master'?by?3?commits.
??(use?"git?push"?to?publish?your?local?commits)
nothing?to?commit,?working?tree?clean
加上剛才合并的提交，現在我們本地分支比遠程分支超前3個提交。
- 用git log看看：
*???e0ea545?(HEAD?->?master)?Merge?branch?'master'?of?github.com:michaelliao/learngit
|\??
|?*?f005ed4?(origin/master)?set?exit=1
*?|?582d922?add?author
*?|?8875536?add?comment
|/??
*?d1be385?init?hello
...
- 我們輸入命令git rebase試試：
First,?rewinding?head?to?replay?your?work?on?top?of?it...
Applying:?add?comment
Using?index?info?to?reconstruct?a?base?tree...
M?hello.py
Falling?back?to?patching?base?and?3-way?merge...
Auto-merging?hello.py
Applying:?add?author
Using?index?info?to?reconstruct?a?base?tree...
M?hello.py
Falling?back?to?patching?base?and?3-way?merge...
Auto-merging?hello.py
輸出了一大堆操作，到底是啥效果？再用git log看看：
$?git?log?--graph?--pretty=oneline?--abbrev-commit*?7e61ed4?(HEAD?->?master)?add?author
*?3611cfe?add?comment
*?f005ed4?(origin/master)?set?exit=1
*?d1be385?init?hello
...
原本分叉的提交現在變成一條直線了！這種神奇的操作是怎么實現的？其實原理非常簡單。我們注意觀察，發現Git把我們本地的提交“挪動”了位置，放到了f005ed4 (origin/master) set exit=1之后，這樣，整個提交歷史就成了一條直線。rebase操作前后，最終的提交內容是一致的，但是，我們本地的commit修改內容已經變化了，它們的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4內容是一致的。
- 這就是rebase操作的特點：把分叉的提交歷史“整理”成一條直線，看上去更直觀。缺點是本地的分叉提交已經被修改過了。
最后，通過push操作把本地分支推送到遠程：
$?git?push?origin?masterCounting?objects:?6,?done.
Delta?compression?using?up?to?4?threads.
Compressing?objects:?100%?(5/5),?done.
Writing?objects:?100%?(6/6),?576?bytes?|?576.00?KiB/s,?done.
Total?6?(delta?2),?reused?0?(delta?0)
remote:?Resolving?deltas:?100%?(2/2),?completed?with?1?local?object.
To?github.com:michaelliao/learngit.git
???f005ed4..7e61ed4??master?->?master
再用git log看看效果：
$?git?log?--graph?--pretty=oneline?--abbrev-commit*?7e61ed4?(HEAD?->?master,?origin/master)?add?author
*?3611cfe?add?comment
*?f005ed4?set?exit=1
*?d1be385?init?hello
...
遠程分支的提交歷史也是一條直線。
總結
以上是生活随笔為你收集整理的git 为什么会有多个head_继续学习Git的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java的object如何转为具体的类_
- 下一篇： 图书馆座位预定管理系统前端设计_图书馆座