理解git分支-遠程分支

遠程分支

遠程引用是對遠程倉庫的引用(指針),包括分支、標籤等等。 你能夠經過 git ls-remote (remote)來顯式地得到遠程引用的完整列表,或者經過 git remote show (remote) 得到遠程分支的更多信息。 然而,一個更常見的作法是利用遠程跟蹤分支。git

遠程跟蹤分支是遠程分支狀態的引用。 它們是你不能移動的本地引用,當你作任何網絡通訊操做時,它們會自動移動。 遠程跟蹤分支像是你上次鏈接到遠程倉庫時,那些分支所處狀態的書籤。github

它們以 (remote)/(branch) 形式命名。 例如,若是你想要看你最後一次與遠程倉庫 origin 通訊時master 分支的狀態,你能夠查看 origin/master 分支。 你與同事合做解決一個問題而且他們推送了一個 iss53 分支,你可能有本身的本地 iss53 分支;可是在服務器上的分支會指向 origin/iss53 的提交。數據庫

這可能有一點兒難以理解,讓咱們來看一個例子。 假設你的網絡裏有一個在 git.ourcompany.com 的 Git 服務器。 若是你從這裏克隆,Git 的 clone 命令會爲你自動將其命名爲 origin,拉取它的全部數據,建立一個指向它的 master 分支的指針,而且在本地將其命名爲 origin/master。 Git 也會給你一個與 origin 的 master 分支在指向同一個地方的本地 master 分支,這樣你就有工做的基礎。緩存

NOTE

「origin」 並沒有特殊含義

遠程倉庫名字 「origin」 與分支名字 「master」 同樣,在 Git 中並無任何特別的含義同樣。 同時 「master」 是當你運行 git init 時默認的起始分支名字,緣由僅僅是它的普遍使用,「origin」 是當你運行 git clone 時默認的遠程倉庫名字。 若是你運行 git clone -o booyah,那麼你默認的遠程分支名字將會是 booyah/master服務器

克隆以後的服務器與本地倉庫。Figure 3-22. 克隆以後的服務器與本地倉庫網絡

若是你在本地的 master 分支作了一些工做,然而在同一時間,其餘人推送提交到git.ourcompany.com 並更新了它的 master 分支,那麼你的提交歷史將向不一樣的方向前進。 也許,只要你不與 origin 服務器鏈接,你的 origin/master 指針就不會移動。學習

本地與遠程的工做能夠分叉。Figure 3-23. 本地與遠程的工做能夠分叉fetch

若是要同步你的工做,運行 git fetch origin 命令。 這個命令查找 「origin」 是哪個服務器(在本例中,它是 git.ourcompany.com),從中抓取本地沒有的數據,而且更新本地數據庫,移動origin/master 指針指向新的、更新後的位置。this

`git fetch` 更新你的遠程倉庫引用。Figure 3-24. git fetch 更新你的遠程倉庫引用spa

爲了演示有多個遠程倉庫與遠程分支的狀況,咱們假定你有另外一個內部 Git 服務器,僅用於你的 sprint 小組的開發工做。 這個服務器位於 git.team1.ourcompany.com。 你能夠運行 git remote add 命令添加一個新的遠程倉庫引用到當前的項目,這個命令咱們會在 Git 基礎 中詳細說明。 將這個遠程倉庫命名爲 teamone,將其做爲整個 URL 的縮寫。

添加另外一個遠程倉庫。Figure 3-25. 添加另外一個遠程倉庫

如今,能夠運行 git fetch teamone 來抓取遠程倉庫 teamone 有而本地沒有的數據。 由於那臺服務器上現有的數據是 origin 服務器上的一個子集,因此 Git 並不會抓取數據而是會設置遠程跟蹤分支teamone/master 指向 teamone 的 master 分支。

遠程跟蹤分支 `teamone/master`。Figure 3-26. 遠程跟蹤分支 teamone/master

推送

當你想要公開分享一個分支時,須要將其推送到有寫入權限的遠程倉庫上。 本地的分支並不會自動與遠程倉庫同步 - 你必須顯式地推送想要分享的分支。 這樣,你就能夠把不肯意分享的內容放到私人分支上,而將須要和別人協做的內容推送到公開分支。

若是但願和別人一塊兒在名爲 serverfix 的分支上工做,你能夠像推送第一個分支那樣推送它。 運行 git push (remote) (branch):

 git push origin serverfix






$Counting objects: 24, done.Delta compression using up to 8 threads.Compressing objects: 100% (15/15), done.Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.Total 24 (delta 2), reused 0 (delta 0)To https://github.com/schacon/simplegit* [new branch]      serverfix -> serverfix

這裏有些工做被簡化了。 Git 自動將 serverfix 分支名字展開爲refs/heads/serverfix:refs/heads/serverfix,那意味着,「推送本地的 serverfix 分支來更新遠程倉庫上的 serverfix 分支。」 咱們將會詳細學習 Git 內部原理 的 refs/heads/ 部分,可是如今能夠先把它放在兒。 你也能夠運行 git push origin serverfix:serverfix,它會作一樣的事 - 至關於它說,「推送本地的 serverfix 分支,將其做爲遠程倉庫的 serverfix 分支」 能夠經過這種格式來推送本地分支到一個命名不相同的遠程分支。 若是並不想讓遠程倉庫上的分支叫作 serverfix,能夠運行 git push origin serverfix:awesomebranch 來將本地的 serverfix 分支推送到遠程倉庫上的awesomebranch 分支。

NOTE

如何避免每次輸入密碼

若是你正在使用 HTTPS URL 來推送,Git 服務器會詢問用戶名與密碼。 默認狀況下它會在終端中提示服務器是否容許你進行推送。

若是不想在每一次推送時都輸入用戶名與密碼,你能夠設置一個 「credential cache」。 最簡單的方式就是將其保存在內存中幾分鐘,能夠簡單地運行 git config --global credential.helper cache 來設置它。

想要了解更多關於不一樣驗證緩存的可用選項,查看 憑證存儲

下一次其餘協做者從服務器上抓取數據時,他們會在本地生成一個遠程分支 origin/serverfix,指向服務器的 serverfix 分支的引用:

 git fetch origin





$remote: Counting objects: 7, done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 3 (delta 0)Unpacking objects: 100% (3/3), done.From https://github.com/schacon/simplegit* [new branch]      serverfix    -> origin/serverfix

要特別注意的一點是當抓取到新的遠程跟蹤分支時,本地不會自動生成一份可編輯的副本(拷貝)。 換一句話說,這種狀況下,不會有一個新的 serverfix 分支 - 只有一個不能夠修改的 origin/serverfix指針。

能夠運行 git merge origin/serverfix 將這些工做合併到當前所在的分支。 若是想要在本身的serverfix 分支上工做,能夠將其創建在遠程跟蹤分支之上:

 git checkout -b serverfix origin/serverfix

$Branch serverfix set up to track remote branch serverfix from origin.Switched to a new branch 'serverfix'

這會給你一個用於工做的本地分支,而且起點位於 origin/serverfix

跟蹤分支

從一個遠程跟蹤分支檢出一個本地分支會自動建立一個叫作 「跟蹤分支」(有時候也叫作 「上游分支」)。 跟蹤分支是與遠程分支有直接關係的本地分支。 若是在一個跟蹤分支上輸入 git pull,Git 能自動地識別去哪一個服務器上抓取、合併到哪一個分支。

當克隆一個倉庫時,它一般會自動地建立一個跟蹤 origin/master 的 master 分支。 然而,若是你願意的話能夠設置其餘的跟蹤分支 - 其餘遠程倉庫上的跟蹤分支,或者不跟蹤 master 分支。 最簡單的就是以前看到的例子,運行 git checkout -b [branch] [remotename]/[branch]。 這是一個十分經常使用的操做因此 Git 提供了 --track 快捷方式:

 git checkout --track origin/serverfix

$Branch serverfix set up to track remote branch serverfix from origin.Switched to a new branch 'serverfix'

若是想要將本地分支與遠程分支設置爲不一樣名字,你能夠輕鬆地增長一個不一樣名字的本地分支的上一個命令:

 git checkout -b sf origin/serverfix

$Branch sf set up to track remote branch serverfix from origin.Switched to a new branch 'sf'

如今,本地分支 sf 會自動從 origin/serverfix 拉取。

設置已有的本地分支跟蹤一個剛剛拉取下來的遠程分支,或者想要修改正在跟蹤的上游分支,你能夠在任意時間使用 -u 或 --set-upstream-to 選項運行 git branch 來顯式地設置。

 git branch -u origin/serverfix
$Branch serverfix set up to track remote branch serverfix from origin.
NOTE

上游快捷方式

當設置好跟蹤分支後,能夠經過 @{upstream} 或 @{u} 快捷方式來引用它。 因此在 master分支時而且它正在跟蹤 origin/master 時,若是願意的話可使用 git merge @{u} 來取代git merge origin/master

若是想要查看設置的全部跟蹤分支,可使用 git branch 的 -vv 選項。 這會將全部的本地分支列出來而且包含更多的信息,如每個分支正在跟蹤哪一個遠程分支與本地分支是不是領先、落後或是都有。

 git branch -vv



$iss53     7e424c3 [origin/iss53: ahead 2] forgot the bracketsmaster    1ae2a45 [origin/master] deploying index fix* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do ittesting   5ea463a trying something new

這裏能夠看到 iss53 分支正在跟蹤 origin/iss53 而且 「ahead」 是 2,意味着本地有兩個提交尚未推送到服務器上。 也能看到 master 分支正在跟蹤 origin/master 分支而且是最新的。 接下來能夠看到 serverfix 分支正在跟蹤 teamone 服務器上的 server-fix-good 分支而且領先 2 落後 1,意味着服務器上有一次提交尚未合併入同時本地有三次提交尚未推送。 最後看到 testing 分支並無跟蹤任何遠程分支。

須要重點注意的一點是這些數字的值來自於你從每一個服務器上最後一次抓取的數據。 這個命令並無鏈接服務器,它只會告訴你關於本地緩存的服務器數據。 若是想要統計最新的領先與落後數字,須要在運行此命令前抓取全部的遠程倉庫。 能夠像這樣作:$ git fetch --all; git branch -vv

拉取

當 git fetch 命令從服務器上抓取本地沒有的數據時,它並不會修改工做目錄中的內容。 它只會獲取數據而後讓你本身合併。 然而,有一個命令叫做 git pull 在大多數狀況下它的含義是一個 git fetch 緊接着一個 git merge 命令。 若是有一個像以前章節中演示的設置好的跟蹤分支,無論它是顯式地設置仍是經過 clone 或 checkout 命令爲你建立的,git pull 都會查找當前分支所跟蹤的服務器與分支,從服務器上抓取數據而後嘗試合併入那個遠程分支。

因爲 git pull 的魔法常常使人困惑因此一般單獨顯式地使用 fetch 與 merge 命令會更好一些。

刪除遠程分支

假設你已經經過遠程分支作完全部的工做了 - 也就是說你和你的協做者已經完成了一個特性而且將其合併到了遠程倉庫的 master 分支(或任何其餘穩定代碼分支)。 能夠運行帶有 --delete 選項的 git push命令來刪除一個遠程分支。 若是想要從服務器上刪除 serverfix 分支,運行下面的命令:

 git push origin --delete serverfix

$To https://github.com/schacon/simplegit- [deleted]         serverfix

基本上這個命令作的只是從服務器上移除這個指針。 Git 服務器一般會保留數據一段時間直到垃圾回收運行,因此若是不當心刪除掉了,一般是很容易恢復的。

相關文章
相關標籤/搜索