分支管理
分支就是科幻電影里面的平行宇宙，當(dāng)你正在電腦前努力學(xué)習(xí)Git的時候，另一個你正在另一個平行宇宙里努力學(xué)習(xí)SVN。
如果兩個平行宇宙互不干擾，那對現(xiàn)在的你也沒啥影響。不過，在某個時間點，兩個平行宇宙合并了，結(jié)果，你既學(xué)會了Git又學(xué)會了SVN！
分支在實際中有什么用呢？假設(shè)你準(zhǔn)備開發(fā)一個新功能，但是需要兩周才能完成，第一周你寫了50%的代碼，如果立刻提交，由于代碼還沒寫完，不完整的代碼庫會導(dǎo)致別人不能干活了。如果等代碼全部寫完再一次提交，又存在丟失每天進(jìn)度的巨大風(fēng)險。
現(xiàn)在有了分支，就不用怕了。你創(chuàng)建了一個屬于你自己的分支，別人看不到，還繼續(xù)在原來的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到開發(fā)完畢后，再一次性合并到原來的分支上，這樣，既安全，又不影響別人工作。
其他版本控制系統(tǒng)如SVN等都有分支管理，但是用過之后你會發(fā)現(xiàn)，這些版本控制系統(tǒng)創(chuàng)建和切換分支比蝸牛還慢，簡直讓人無法忍受，結(jié)果分支功能成了擺設(shè)，大家都不去用。
但Git的分支是與眾不同的，無論創(chuàng)建、切換和刪除分支，Git在1秒鐘之內(nèi)就能完成！無論你的版本庫是1個文件還是1萬個文件。
1.創(chuàng)建與合并分支
在版本回退里，你已經(jīng)知道，每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，在Git里，這個分支叫主分支，即master分支。HEAD嚴(yán)格來說不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是當(dāng)前分支。
一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能確定當(dāng)前分支，以及當(dāng)前分支的提交點：
每次提交，master分支都會向前移動一步，這樣，隨著你不斷提交，master分支的線也越來越長：
當(dāng)我們創(chuàng)建新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當(dāng)前分支在dev上：
你看，Git創(chuàng)建一個分支很快，因為除了增加一個dev指針，改改HEAD的指向，工作區(qū)的文件都沒有任何變化！
不過，從現(xiàn)在開始，對工作區(qū)的修改和提交就是針對dev分支了，比如新提交一次后，dev指針往前移動一步，而master指針不變：
假如我們在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最簡單的方法，就是直接把master指向dev的當(dāng)前提交，就完成了合并：
所以Git合并分支也很快！就改改指針，工作區(qū)內(nèi)容也不變！
合并完分支后，甚至可以刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉后，我們就剩下了一條master分支：
真是太神奇了，你看得出來有些提交是通過分支完成的嗎？
下面開始實戰(zhàn)。
首先，我們創(chuàng)建dev分支，然后切換到dev分支：
<pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; word-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">$ git checkout -b dev
Switched to a new branch 'dev'</pre>
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命令會列出所有分支，當(dāng)前分支前面會標(biāo)一個*號。
然后，我們就可以在dev分支上正常提交，比如對readme.txt做個修改，加上一行：
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分支后，再查看一個readme.txt文件，剛才添加的內(nèi)容不見了！因為那個提交是在dev分支上，而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，我們后面會講其他方式的合并。
合并完成后，就可以放心地刪除dev分支了：
<pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; word-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">$ git branch -d dev
Deleted branch dev (was fec145a).</pre>
刪除后，查看branch，就只剩下master分支了：
$ git branch * master
因為創(chuàng)建、合并和刪除分支非?？?，所以Git鼓勵你使用分支完成某個任務(wù)，合并后再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。
小結(jié)
Git鼓勵大量使用分支：
查看分支：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>
2.解決沖突
人生不如意之事十之八九，合并分支往往也不是一帆風(fēng)順的。
準(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個提交。
在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無法執(zhí)行“快速合并”，只能試圖把各自的修改合并起來，但這種合并就可能會有沖突，我們試試看：
$ 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文件存在沖突，必須手動解決沖突后再提交。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)容：
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. <<<<<<< 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分支變成了下圖所示：
用帶參數(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無法自動合并分支時，就必須首先解決沖突。解決沖突后，再提交，合并完成。
用git log --graph命令可以看到分支合并圖。
3.分支管理策略
通常，合并分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支后，會丟掉分支信息。
如果要強(qiáng)制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。
下面我們實戰(zhàn)一下--no-ff方式的git merge：
首先，仍然創(chuàng)建并切換dev分支：
$ git checkout -b dev
Switched to a new branch 'dev'
修改readme.txt文件，并提交一個新的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分支，請注意--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(+)
因為本次合并要創(chuàng)建一個新的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</pre>
可以看到，不使用Fast forward模式，merge后就像這樣：
分支策略
在實際開發(fā)中，我們應(yīng)該按照幾個基本原則進(jìn)行分支管理：
首先，master分支應(yīng)該是非常穩(wěn)定的，也就是僅用來發(fā)布新版本，平時不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是說，dev分支是不穩(wěn)定的，到某個時候，比如1.0版本發(fā)布時，再把dev分支合并到master上，在master分支發(fā)布1.0版本；
你和你的小伙伴們每個人都在dev分支上干活，每個人都有自己的分支，時不時地往dev分支上合并就可以了。
所以，團(tuán)隊合作的分支看起來就像這樣：
小結(jié)
Git分支十分強(qiáng)大，在團(tuán)隊開發(fā)中應(yīng)該充分應(yīng)用。
合并分支時，加上--no-ff參數(shù)就可以用普通模式合并，合并后的歷史有分支，能看出來曾經(jīng)做過合并，而fast forward合并就看不出來曾經(jīng)做過合并。
4.Bug分支
軟件開發(fā)中，bug就像家常便飯一樣。有了bug就需要修復(fù)，在Git中，由于分支是如此的強(qiáng)大，所以，每個bug都可以通過一個新的臨時分支來修復(fù)，修復(fù)后，合并分支，然后將臨時分支刪除。
當(dāng)你接到一個修復(fù)一個代號101的bug的任務(wù)時，很自然地，你想創(chuàng)建一個分支issue-101來修復(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ù)計完成還需1天時間。但是，必須在兩個小時內(nèi)修復(fù)該bug，怎么辦？
幸好，Git還提供了一個stash功能，可以把當(dāng)前工作現(xiàn)場“儲藏”起來，等以后恢復(fù)現(xiàn)場后繼續(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)建分支來修復(fù)bug。
首先確定要在哪個分支上修復(fù)bug，假定需要在master分支上修復(fù)，就從master創(chuàng)建臨時分支：
<pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; word-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">$ 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'</pre>
現(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ù)只花了5分鐘！現(xiàn)在，是時候接著回到dev分支干活了！
$ git checkout dev
Switched to branch 'dev'
$ git status
# On branch dev
nothing to commit (working directory clean)
工作區(qū)是干凈的，剛才的工作現(xiàn)場存到哪去了？用git stash list命令看看：
$ git stash list
stash@{0}: WIP on dev: 6224937 add merge
工作現(xiàn)場還在，Git把stash內(nèi)容存在某個地方了，但是需要恢復(fù)一下，有兩個辦法：
一是用git stash apply恢復(fù)，但是恢復(fù)后，stash內(nèi)容并不刪除，你需要用git stash drop來刪除；
另一種方式是用git stash pop，恢復(fù)的同時把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ù)的時候，先用git stash list查看，然后恢復(fù)指定的stash，用命令：
$ git stash apply stash@{0}
小結(jié)
修復(fù)bug時，我們會通過創(chuàng)建新的bug分支進(jìn)行修復(fù)，然后合并，最后刪除；
當(dāng)手頭工作沒有完成時，先把工作現(xiàn)場git stash一下，然后去修復(fù)bug，修復(fù)后，再git stash pop，回到工作現(xiàn)場。
5.Feature分支
軟件開發(fā)中，總有無窮無盡的新的功能要不斷添加進(jìn)來。
添加一個新功能時，你肯定不希望因為一些實驗性質(zhì)的代碼，把主分支搞亂了，所以，每添加一個新功能，最好新建一個feature分支，在上面開發(fā)，完成后，合并，最后，刪除該feature分支。
現(xiàn)在，你終于接到了一個新任務(wù)：開發(fā)代號為Vulcan的新功能，該功能計劃用于下一代星際飛船。
于是準(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分支是類似的，合并，然后刪除。
但是，
就在此時，接到上級命令，因經(jīng)費不足，新功能必須取消！
雖然白干了，但是這個分支還是必須就地銷毀：
$ 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ā)一個新feature，最好新建一個分支；
如果要丟棄一個沒有被合并過的分支，可以通過git branch -D <name>強(qiáng)行刪除。
終于刪除成功！
6.多人協(xié)作
當(dāng)你從遠(yuǎn)程倉庫克隆時，實際上Git自動把本地的master分支和遠(yuǎn)程的master分支對應(yīng)起來了，并且，遠(yuǎn)程倉庫的默認(rèn)名稱是origin。
要查看遠(yuǎn)程庫的信息，用git remote：
$ git remote
origin
或者，用git remote -v顯示更詳細(xì)的信息：
$ git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
上面顯示了可以抓取和推送的origin的地址。如果沒有推送權(quán)限，就看不到push的地址。
推送分支
推送分支，就是把該分支上的所有本地提交推送到遠(yuǎn)程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠(yuǎn)程庫對應(yīng)的遠(yuǎn)程分支上：
<pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; word-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">$ git push origin master</pre>
如果要推送其他分支，比如dev，就改成：
<pre style="margin-top: 0px; margin-bottom: 0px; white-space: pre-wrap; word-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">$ git push origin dev</pre>
但是，并不是一定要把本地分支往遠(yuǎn)程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要時刻與遠(yuǎn)程同步；dev分支是開發(fā)分支，團(tuán)隊所有成員都需要在上面工作，所以也需要與遠(yuǎn)程同步；bug分支只用于在本地修復(fù)bug，就沒必要推到遠(yuǎn)程了，除非老板要看看你每周到底修復(fù)了幾個bug；
feature分支是否推到遠(yuǎn)程，取決于你是否和你的小伙伴合作在上面開發(fā)。
總之，就是在Git中，分支完全可以在本地自己藏著玩，是否推送，視你的心情而定！
抓取分支
多人協(xié)作時，大家都會往master和dev分支上推送各自的修改。
現(xiàn)在，模擬一個你的小伙伴，可以在另一臺電腦（注意要把SSH Key添加到GitHub）或者同一臺電腦的另一個目錄下克?。?/p>
$ git clone git@github.com:michaelliao/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)程庫clone時，默認(rèn)情況下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：
$ git branch * master
現(xiàn)在，你的小伙伴要在dev分支上開發(fā)，就必須創(chuàng)建遠(yuǎn)程origin的dev分支到本地，于是他用這個命令創(chuàng)建本地dev分支：
$ git checkout -b dev origin/dev
現(xiàn)在，他就可以在dev上繼續(xù)修改，然后，時不時地把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分支推送了他的提交，而碰巧你也對同樣的文件作了修改，并試圖推送：
$ 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.
推送失敗，因為你的小伙伴的最新提交和你試圖推送的提交有沖突，解決辦法也很簡單，Git已經(jīng)提示我們，先用git pull把最新的提交從origin/dev抓下來，然后，在本地合并，解決沖突，再推送：
$ 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成功，但是合并有沖突，需要手動解決，解決的方法和分支管理中的解決沖突完全一樣。解決后，提交，再push：
$ 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推送自己的修改；如果推送失敗，則因為遠(yuǎn)程分支比你的本地更新，需要先用
git pull試圖合并；如果合并有沖突，則解決沖突，并在本地提交；
沒有沖突或者解決掉沖突后，再用
git push origin branch-name推送就能成功！
如果git pull提示“no tracking information”，則說明本地分支和遠(yuǎn)程分支的鏈接關(guān)系沒有創(chuàng)建，用命令git branch --set-upstream branch-name origin/branch-name。
這就是多人協(xié)作的工作模式，一旦熟悉了，就非常簡單。
小結(jié)
查看遠(yuǎn)程庫信息，使用
git remote -v；本地新建的分支如果不推送到遠(yuǎn)程，對其他人就是不可見的；
從本地推送分支，使用
git push origin branch-name，如果推送失敗，先用git pull抓取遠(yuǎn)程的新提交；在本地創(chuàng)建和遠(yuǎn)程分支對應(yīng)的分支，使用
git checkout -b branch-name origin/branch-name，本地和遠(yuǎn)程分支的名稱最好一致；建立本地分支和遠(yuǎn)程分支的關(guān)聯(lián)，使用
g**it branch --set-upstream branch-name origin/branch-name**；從遠(yuǎn)程抓取分支，使用
git pull，如果有沖突，要先處理沖突。
轉(zhuǎn)載原文地址：https://www.cnblogs.com/benjamin77/p/8625933.html
