遠程倉庫

到目前爲止，我們已經掌握瞭如何在Git倉庫裏對一個文件進行時光穿梭，你再也不用擔心文件備份或者丟失的問題了。

可是有用過集中式版本控制系統SVN的童鞋會站出來說，這些功能在SVN裏早就有了，沒看出Git有什麼特別的地方。

沒錯，如果只是在一個倉庫裏管理文件歷史，Git和SVN真沒啥區別。爲了保證你現在所學的Git物超所值，將來絕對不會後悔，同時爲了打擊已經不幸學了SVN的童鞋，本章開始介紹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 "[email protected]"

你需要把郵件地址換成你自己的郵件地址，然後一路回車，使用默認值即可，由於這個Key也不是用於軍事目的，所以也無需設置密碼。

如果一切順利的話，可以在用戶主目錄裏找到.ssh目錄，裏面有id_rsa和id_rsa.pub兩個文件，這兩個就是SSH Key的祕鑰對，id_rsa是私鑰，不能泄露出去，id_rsa.pub是公鑰，可以放心地告訴任何人。

第2步：登陸GitHub，打開“Settings”，“SSH Keys”頁面：
然後，點“SSH and GPG keys”，填上任意Title，在Key文本框裏粘貼id_rsa.pub文件的內容：

爲什麼GitHub需要SSH Key呢？因爲GitHub需要識別出你推送的提交確實是你推送的，而不是別人冒充的，而Git支持SSH協議，所以，GitHub只要知道了你的公鑰，就可以確認只有你自己才能推送。

當然，GitHub允許你添加多個Key。假定你有若干電腦，你一會兒在公司提交，一會兒在家裏提交，只要把每臺電腦的Key都添加到GitHub，就可以在每臺電腦上往GitHub推送了。

最後友情提示，在GitHub上免費託管的Git倉庫，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放進去。

如果你不想讓別人看到Git庫，有兩個辦法，一個是交點保護費，讓GitHub把公開的倉庫變成私有的，這樣別人就看不見了（不可讀更不可寫）。另一個辦法是自己動手，搭一個Git服務器，因爲是你自己的Git服務器，所以別人也是看不見的。這個方法我們後面會講到的，相當簡單，公司內部開發必備。

確保你擁有一個GitHub賬號後，我們就即將開始遠程倉庫的學習。

小結

“有了遠程倉庫，媽媽再也不用擔心我的硬盤了。”——Git點讀機

添加遠程庫

現在的情景是，你已經在本地創建了一個Git倉庫後，又想在GitHub創建一個Git倉庫，並且讓這兩個倉庫進行遠程同步，這樣，GitHub上的倉庫既可以作爲備份，又可以讓其他人通過該倉庫來協作，真是一舉多得。

首先，登陸GitHub，創建一個新的倉庫：

在Repository name填入learngit，其他保持默認設置，點擊“Create repository”按鈕，就成功地創建了一個新的Git倉庫：

目前，在GitHub上的這個learngit倉庫還是空的，GitHub告訴我們，可以從這個倉庫克隆出新的倉庫，也可以把一個已有的本地倉庫與之關聯，然後，把本地倉庫的內容推送到GitHub倉庫。

現在，我們根據GitHub的提示，在本地的learngit倉庫下運行命令：

git remote add origin https://github.com/9aoyang/learngit.git

添加後，遠程庫的名字就是origin，這是Git默認的叫法，也可以改成別的，但是origin這個名字一看就知道是遠程庫:

$ git push -u origin master
Counting objects: 17, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (17/17), 1.43 KiB | 0 bytes/s, done.
Total 17 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), done.
To https://github.com/9aoyang/learngit.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

把本地庫的內容推送到遠程，用git push命令，實際上是把當前分支master推送到遠程。

由於遠程庫是空的，我們第一次推送master分支時，加上了-u參數，Git不但會把本地的master分支內容推送的遠程新的master分支，還會把本地的master分支和遠程的master分支關聯起來，在以後的推送或者拉取時就可以簡化命令。

推送成功後，可以立刻在GitHub頁面中看到遠程庫的內容已經和本地一模一樣：

從現在起，只要本地作了提交，就可以通過命令：

$ git push origin master

把本地master分支的最新修改推送至GitHub，現在，你就擁有了真正的分佈式版本庫！

SSH警告
當你第一次使用Git的clone或者push命令連接GitHub時，會得到一個警告：

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

這是因爲Git使用SSH連接，而SSH連接在第一次驗證GitHub服務器的Key時，需要你確認GitHub的Key的指紋信息是否真的來自GitHub的服務器，輸入yes回車即可。

Git會輸出一個警告，告訴你已經把GitHub的Key添加到本機的一個信任列表裏了：

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.

如果你實在擔心有人冒充GitHub服務器，輸入yes
前可以對照GitHub的RSA Key的指紋信息是否與SSH連接給出的一致。

小結

要關聯一個遠程庫，使用命令git remote add origin git@server-name:path/repo-name.git；

關聯後，使用命令git push -u origin master第一次推送master分支的所有內容；

此後，每次本地提交後，只要有必要，就可以使用命令git push origin master推送最新修改；

分佈式版本系統的最大好處之一是在本地工作完全不需要考慮遠程庫的存在，也就是有沒有聯網都可以正常工作，而SVN在沒有聯網的時候是拒絕幹活的！當有網絡的時候，再把本地提交推送一下就完成了同步，真是太方便了！

從遠程庫克隆

上次我們講了先有本地庫，後有遠程庫的時候，如何關聯遠程庫。

現在，假設我們從零開發，那麼最好的方式是先創建遠程庫，然後，從遠程庫克隆。

首先，登陸GitHub，創建一個新的倉庫，名字叫gitskills：

我們勾選Initialize this repository with a README，這樣GitHub會自動爲我們創建一個README.md文件。創建完畢後，可以看到README.md文件：

Paste_Image.png

現在，遠程庫已經準備好了，下一步是用命令git clone克隆一個本地庫：

$ git clone [email protected]:9aoyang/gitskills.git
Cloning into 'gitskills'...
The authenticity of host 'github.com (192.30.255.112)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,192.30.255.112' (RSA) to the list of known hosts.
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

$ cd gitskills
$ ls
README.md

注意把Git庫的地址換成你自己的，然後進入gitskills目錄看看，已經有README.md文件了。

如果有多個人協作開發，那麼每個人各自從遠程克隆一份就可以了。

你也許還注意到，GitHub給出的地址不止一個，還可以用https://github.com/michaelliao/gitskills.git這樣的地址。實際上，Git支持多種協議，默認的git://使用ssh，但也可以使用https等其他協議。

使用https除了速度慢以外，還有個最大的麻煩是每次推送都必須輸入口令，但是在某些只開放http端口的公司內部就無法使用ssh協議而只能用https。

小結

要克隆一個倉庫，首先必須知道倉庫的地址，然後使用git clone命令克隆。

Git支持多種協議，包括https，但通過ssh支持的原生git協議速度最快。

分支管理

分支就是科幻電影裏面的平行宇宙，當你正在電腦前努力學習Git的時候，另一個你正在另一個平行宇宙裏努力學習SVN。

如果兩個平行宇宙互不干擾，那對現在的你也沒啥影響。不過，在某個時間點，兩個平行宇宙合併了，結果，你既學會了Git又學會了SVN！

learn-branches

分支在實際中有什麼用呢？假設你準備開發一個新功能，但是需要兩週才能完成，第一週你寫了50%的代碼，如果立刻提交，由於代碼還沒寫完，不完整的代碼庫會導致別人不能幹活了。如果等代碼全部寫完再一次提交，又存在丟失每天進度的巨大風險。

現在有了分支，就不用怕了。你創建了一個屬於你自己的分支，別人看不到，還繼續在原來的分支上正常工作，而你在自己的分支上幹活，想提交就提交，直到開發完畢後，再一次性合併到原來的分支上，這樣，既安全，又不影響別人工作。

其他版本控制系統如SVN等都有分支管理，但是用過之後你會發現，這些版本控制系統創建和切換分支比蝸牛還慢，簡直讓人無法忍受，結果分支功能成了擺設，大家都不去用。

但Git的分支是與衆不同的，無論創建、切換和刪除分支，Git在1秒鐘之內就能完成！無論你的版本庫是1個文件還是1萬個文件。

創建與合併分支

每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，在Git裏，這個分支叫主分支，即master分支。HEAD嚴格來說不是指向提交，而是指向master，master纔是指向提交的，所以，HEAD指向的就是當前分支。

一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能確定當前分支，以及當前分支的提交點：

每次提交，master分支都會向前移動一步，這樣，隨着你不斷提交，master分支的線也越來越長：

當我們創建新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當前分支在dev上：

假如我們在dev上的工作完成了，就可以把dev合併到master上。Git怎麼合併呢？最簡單的方法，就是直接把master指向dev的當前提交，就完成了合併：

所以Git合併分支也很快！就改改指針，工作區內容也不變！

合併完分支後，甚至可以刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉後，我們就剩下了一條master分支：

下面開始實戰。

首先，我們創建dev分支，然後切換到dev分支：

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

git checkout命令加上-b參數表示創建並切換，相當於以下兩條命令：

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

然後，用git branch命令查看當前分支：

$ git branch
* dev
  master

git branch命令會列出所有分支，當前分支前面會標一個*號。

然後，我們就可以在dev分支上正常提交，比如對readme.txt做個修改，加上一行：

Creating a new branch is quick.

然後提交：

$ git add README.md
$ git commit -m "branch test"
[dev cc10569] branch test
 1 file changed, 2 insertions(+), 1 deletion(-)

現在，dev分支的工作完成，我們就可以切換回master分支：

$ git checkout master
Switched to branch 'master'

切換回master分支後，再查看一個readme.txt文件，剛纔添加的內容不見了！因爲那個提交是在dev分支上，而master分支此刻的提交點並沒有變：

現在，我們把dev分支的工作成果合併到master分支上：

$ git merge dev
Updating 238d90f..cc10569
Fast-forward
 README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

git merge命令用於合併指定分支到當前分支。合併後，再查看readme.txt的內容，就可以看到，和dev分支的最新提交是完全一樣的。

注意到上面的Fast-forward信息，Git告訴我們，這次合併是“快進模式”，也就是直接把master指向dev的當前提交，所以合併速度非常快。

當然，也不是每次合併都能Fast-forward，我們後面會講其他方式的合併。

合併完成後，就可以放心地刪除dev分支了：

$ git branch -d dev
Deleted branch dev (was cc10569).

刪除後，查看branch，就只剩下master分支了：

$ git branch
* master

因爲創建、合併和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合併後再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。

小結

Git鼓勵大量使用分支：

查看分支：git branch

創建分支：git branch <name>

切換分支：git checkout <name>

創建+切換分支：git checkout -b <name>

合併某分支到當前分支：git merge <name>

刪除分支：git branch -d <name>

解決衝突

人生不如意之事十之八九，合併分支往往也不是一帆風順的。

準備新的feature1分支，繼續我們的新分支開發：

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

修改README.md最後一行，改爲：

Creating a new branch is quick AND simple.

在feature1分支上提交：

$ git add README.md

$ git commit -m "AND simple"
[feature1 d0dff9f] 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.
  (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.md

$ git commit -m "& simple"
[master 6abbfd7] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)

現在，master分支和feature1分支各自都分別有新的提交，變成了這樣：

這種情況下，Git無法執行“快速合併”，只能試圖把各自的修改合併起來，但這種合併就可能會有衝突，我們試試看：

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

果然衝突了！Git告訴我們，README.md文件存在衝突，必須手動解決衝突後再提交。git status也可以告訴我們衝突的文件：

$ git status
On 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 <file>..." to mark resolution)

        both modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

我們可以直接查看README.md的內容：

$ cat README.md
# gitskills
<<<<<<< HEAD
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.md

$ git commit -m "conflict fixed"
[master 8f9778f] conflict fixed

現在，master分支和feature1分支變成了下圖所示：

用帶參數的git log也可以看到分支的合併情況：

$ git log --graph --pretty=oneline --abbrev-commit
*   8f9778f conflict fixed
|\
| * d0dff9f AND simple
* | 6abbfd7 & simple
|/
* cc10569 branch test
* 238d90f Initial commit

最後，刪除feature1分支：

$ git branch -d feature1
Deleted branch feature1 (was d0dff9f).

工作完成。

小結

當Git無法自動合併分支時，就必須首先解決衝突。解決衝突後，再提交，合併完成。

用git log --graph命令可以看到分支合併圖。

分支管理策略

通常，合併分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支信息。

如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。

下面我們實戰一下--no-ff方式的git merge：
首先，仍然創建並切換dev分支：

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

修改README.md文件，並提交一個新的commit：

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

現在，我們切換回master：

$ git checkout master
Switched to branch 'master'

準備合併dev分支，請注意--no-ff參數，表示禁用Fast forward ：

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

因爲本次合併要創建一個新的commit，所以加上-m參數，把commit描述寫進去。

合併後，我們用git log看看分支歷史：


$ git log --graph --pretty=oneline --abbrev-commit
*   f1eda29 merge with no-ff
|\
| * 45621a8 add merge
|/
*   8f9778f conflict fixed
|\
| * d0dff9f AND simple
* | 6abbfd7 & simple
|/
* cc10569 branch test
...

可以看到，不使用Fast forward模式，merge後就像這樣：

分支策略

在實際開發中，我們應該按照幾個基本原則進行分支管理：

首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面幹活；

那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本；

你和你的小夥伴們每個人都在dev分支上幹活，每個人都有自己的分支，時不時地往dev分支上合併就可以了。

所以，團隊合作的分支看起來就像這樣：

小結

Git分支十分強大，在團隊開發中應該充分應用。

合併分支時，加上--no-ff參數就可以用普通模式合併，合併後的歷史有分支，能看出來曾經做過合併，而fast forward合併就看不出來曾經做過合併。

Bug分支

件開發中，bug就像家常便飯一樣。有了bug就需要修復，在Git中，由於分支是如此的強大，所以，每個bug都可以通過一個新的臨時分支來修復，修復後，合併分支，然後將臨時分支刪除。

當你接到一個修復一個代號101的bug的任務時，很自然地，你想創建一個分支issue-101來修復它，但是，等等，當前正在dev上進行的工作還沒有提交：

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
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

no changes added to commit (use "git add" and/or "git commit -a")

並不是你不想提交，而是工作只進行到一半，還沒法提交，預計完成還需1天時間。但是，必須在兩個小時內修復該bug，怎麼辦？

幸好，Git還提供了一個stash功能，可以把當前工作現場“儲藏”起來，等以後恢復現場後繼續工作：

$ git stash
Saved working directory and index state WIP on master: bb447bf remove test.txt
HEAD is now at bb447bf remove test.txt

現在，用git status查看工作區，就是乾淨的（除非有沒有被Git管理的文件），因此可以放心地創建分支來修復bug。

首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master創建臨時分支：

$ git checkout master
Already on 'master'
Your branch is up-to-date with 'origin/master'.
$ git checkout -b issue-101
Switched to a new branch 'issue-101'

現在修復bug，需要把“Git is free software ...”改爲“Git is a free software ...”，然後提交：

$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 6ebfa69] fix bug 101
 1 file changed, 2 insertions(+), 2 deletions(-)

修復完成後，切換到master分支，並完成合並，最後刪除issue-101分支：

$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
$ git branch -d issue-101
Deleted branch issue-101 (was 6ebfa69).

太棒了，原計劃兩個小時的bug修復只花了5分鐘！現在，是時候接着回到dev分支幹活了！

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

工作區是乾淨的，剛纔的工作現場存到哪去了？用git stash list命令看看：

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

工作現場還在，Git把stash內容存在某個地方了，但是需要恢復一下，有兩個辦法：

一是用git stash apply恢復，但是恢復後，stash內容並不刪除，你需要用git stash drop來刪除；

另一種方式是用git stash pop，恢復的同時把stash內容也刪了：

$ 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內容了：

$ git stash list

你可以多次stash，恢復的時候，先用git stash list查看，然後恢復指定的stash，用命令：

$ git stash apply stash@{0}

小結

修復bug時，我們會通過創建新的bug分支進行修復，然後合併，最後刪除；

當手頭工作沒有完成時，先把工作現場git stash一下，然後去修復bug，修復後，再git stash pop，回到工作現場。

Feature分支

軟件開發中，總有無窮無盡的新的功能要不斷添加進來。

添加一個新功能時，你肯定不希望因爲一些實驗性質的代碼，把主分支搞亂了，所以，每添加一個新功能，最好新建一個feature分支，在上面開發，完成後，合併，最後，刪除該feature分支。

現在，你終於接到了一個新任務：開發代號爲Vulcan的新功能，該功能計劃用於下一代星際飛船。

於是準備開發：

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

五百年後，開發完畢：

$ 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，準備合併：

$ git checkout dev

一切順利的話，feature分支和bug分支是類似的，合併，然後刪除。

但是，

就在此時，接到上級命令，因經費不足，新功能必須取消！

雖然白乾了，但是這個分支還是必須就地銷燬：

$ 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分支還沒有被合併，如果刪除，將丟失掉修改，如果要強行刪除，需要使用命令git branch -D feature-vulcan。
現在我們強行刪除：

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

小結

開發一個新feature，最好新建一個分支；

如果要丟棄一個沒有被合併過的分支，可以通過git branch -D <name>強行刪除。

多人協作

當你從遠程倉庫克隆時，實際上Git自動把本地的master分支和遠程的master分支對應起來了，並且，遠程倉庫的默認名稱是origin。

要查看遠程庫的信息，用git remote：

$ git remote
origin

或者，用git remote -v顯示更詳細的信息：

$ git remote -v
origin  https://github.com/9aoyang/learngit.git (fetch)
origin  https://github.com/9aoyang/learngit.git (push)

上面顯示了可以抓取和推送的origin的地址。如果沒有推送權限，就看不到push的地址。

推送分支
推送分支，就是把該分支上的所有本地提交推送到遠程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：

$ git push origin master

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

$ git push origin dev

但是，並不是一定要把本地分支往遠程推送，那麼，哪些分支需要推送，哪些不需要呢？

master分支是主分支，因此要時刻與遠程同步；
dev分支是開發分支，團隊所有成員都需要在上面工作，所以也需要與遠程同步；
bug分支只用於在本地修復bug，就沒必要推到遠程了，除非老闆要看看你每週到底修復了幾個bug；
feature分支是否推到遠程，取決於你是否和你的小夥伴合作在上面開發。

總之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，視你的心情而定！

抓取分支
多人協作時，大家都會往master和dev分支上推送各自的修改。

現在，模擬一個你的小夥伴，可以在另一臺電腦（注意要把SSH Key添加到GitHub）或者同一臺電腦的另一個目錄下克隆：

$ git clone [email protected]: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.

當你的小夥伴從遠程庫clone時，默認情況下，你的小夥伴只能看到本地的master分支。不信可以用git branch命令看看：

$ git branch
* master

現在，你的小夥伴要在dev分支上開發，就必須創建遠程origin的dev分支到本地，於是他用這個命令創建本地dev分支：

$ git checkout -b dev origin/dev

現在，他就可以在dev上繼續修改，然後，時不時地把dev分支push到遠程：

$ 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 [email protected]:michaelliao/learngit.git
   fc38031..291bea8  dev -> dev

你的小夥伴已經向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 [email protected]:michaelliao/learngit.git
 ! [rejected]        dev -> dev (non-fast-forward)
error: failed to push some refs to '[email protected]: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已經提示我們，先用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分支與遠程origin/dev分支的鏈接，根據提示，設置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 [email protected]:michaelliao/learngit.git
   291bea8..adca45d  dev -> dev

因此，多人協作的工作模式通常是這樣：

首先，可以試圖用git push origin branch-name推送自己的修改；
如果推送失敗，則因爲遠程分支比你的本地更新，需要先用git pull試圖合併；
如果合併有衝突，則解決衝突，並在本地提交；
沒有衝突或者解決掉衝突後，再用git push origin branch-name推送就能成功！

如果git pull提示“no tracking information”，則說明本地分支和遠程分支的鏈接關係沒有創建，用命令git branch --set-upstream branch-name origin/branch-name。

這就是多人協作的工作模式，一旦熟悉了，就非常簡單。

小結

查看遠程庫信息，使用git remote -v；
本地新建的分支如果不推送到遠程，對其他人就是不可見的；
從本地推送分支，使用git push origin branch-name，如果推送失敗，先用git pull抓取遠程的新提交；
在本地創建和遠程分支對應的分支，使用git checkout -b branch-name origin/branch-name，本地和遠程分支的名稱最好一致；
建立本地分支和遠程分支的關聯，使用git branch --set-upstream branch-name origin/branch-name；

從遠程抓取分支，使用git pull，如果有衝突，要先處理衝突。

標籤管理

發佈一個版本時，我們通常先在版本庫中打一個標籤（tag），這樣，就唯一確定了打標籤時刻的版本。將來無論什麼時候，取某個標籤的版本，就是把那個打標籤的時刻的歷史版本取出來。所以，標籤也是版本庫的一個快照。

Git的標籤雖然是版本庫的快照，但其實它就是指向某個commit的指針（跟分支很像對不對？但是分支可以移動，標籤不能移動），所以，創建和刪除標籤都是瞬間完成的。

Git有commit，爲什麼還要引入tag？

“請把上週一的那個版本打包發佈，commit號是6a5819e...”

“一串亂七八糟的數字不好找！”

如果換一個辦法：

“請把上週一的那個版本打包發佈，版本號是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一個讓人容易記住的有意義的名字，它跟某個commit綁在一起。

創建標籤

在Git中打標籤非常簡單，首先，切換到需要打標籤的分支上：

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

然後，敲命令git tag <name>就可以打一個新標籤：

$ git tag v1.0

可以用命令git tag查看所有標籤：

$ git tag
v1.0

默認標籤是打在最新提交的commit上的。有時候，如果忘了打標籤，比如，現在已經是週五了，但應該在週一打的標籤沒有打，怎麼辦？

方法是找到歷史提交的commit id，然後打上就可以了：

$ git log --pretty=oneline --abbrev-commit
6a5819e merged bug fix 101
cc17032 fix bug 101
7825a50 merge with no-ff
6224937 add merge
59bc1cb conflict fixed
400b400 & simple
75a857c AND simple
fec145a branch test
d17efd8 remove test.txt
...

比方說要對add merge這次提交打標籤，它對應的commit id是6224937，敲入命令：

$ git tag v0.9 6224937

再用命令git tag查看標籤：

$ git tag
v0.9
v1.0

注意，標籤不是按時間順序列出，而是按字母排序的。可以用git show <tagname>查看標籤信息：

$ git show v0.9
commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4
Author: Michael Liao <[email protected]>
Date:   Thu Aug 22 11:22:08 2013 +0800

    add merge
...

可以看到，v0.9確實打在add merge這次提交上。
還可以創建帶有說明的標籤，用-a指定標籤名，-m指定說明文字：

$ git tag -a v0.1 -m "version 0.1 released" 3628164

用命令git show <tagname>可以看到說明文字：

$ git show v0.1
tag v0.1
Tagger: Michael Liao <[email protected]>
Date:   Mon Aug 26 07:28:11 2013 +0800

version 0.1 released

commit 3628164fb26d48395383f8f31179f24e0882e1e0
Author: Michael Liao <[email protected]>
Date:   Tue Aug 20 15:11:49 2013 +0800

    append GPL

(暫不用學習)還可以通過-s用私鑰簽名一個標籤：

$ git tag -s v0.2 -m "signed version 0.2 released" fec145a

簽名採用PGP簽名，因此，必須首先安裝gpg（GnuPG），如果沒有找到gpg，或者沒有gpg密鑰對，就會報錯：

gpg: signing failed: secret key not available
error: gpg failed to sign the data
error: unable to sign the tag

如果報錯，請參考GnuPG幫助文檔配置Key。
用命令git show <tagname>可以看到PGP簽名信息：

$ git show v0.2
tag v0.2
Tagger: Michael Liao <[email protected]>
Date:   Mon Aug 26 07:28:33 2013 +0800

signed version 0.2 released
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)

iQEcBAABAgAGBQJSGpMhAAoJEPUxHyDAhBpT4QQIAKeHfR3bo...
-----END PGP SIGNATURE-----

commit fec145accd63cdc9ed95a2f557ea0658a2a6537f
Author: Michael Liao <[email protected]>
Date:   Thu Aug 22 10:37:30 2013 +0800

    branch test

用PGP簽名的標籤是不可僞造的，因爲可以驗證PGP簽名。驗證簽名的方法比較複雜，這裏就不介紹了。

小結

命令git tag <name>用於新建一個標籤，默認爲HEAD，也可以指定一個commit id；
git tag -a <tagname> -m "blablabla..."可以指定標籤信息；
git tag -s <tagname> -m "blablabla..."可以用PGP簽名標籤；
命令git tag可以查看所有標籤。

操作標籤

如果標籤打錯了，也可以刪除：

$ git tag -d v0.1
Deleted tag 'v0.1' (was e078af9)

因爲創建的標籤都只存儲在本地，不會自動推送到遠程。所以，打錯的標籤可以在本地安全刪除。

如果要推送某個標籤到遠程，使用命令git push origin <tagname>：

$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/9aoyang/learngit.git
 * [new tag]         v1.0 -> v1.0

或者，一次性推送全部尚未推送到遠程的本地標籤：

$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/9aoyang/learngit.git
 * [new tag]         v0.9 -> v0.9

如果標籤已經推送到遠程，要刪除遠程標籤就麻煩一點，先從本地刪除：

$ git tag -d v0.9
Deleted tag 'v0.9' (was 6ebfa69)

然後，從遠程刪除。刪除命令也是push，但是格式如下：

$ git push origin :refs/tags/v0.9
To https://github.com/9aoyang/learngit.git
 - [deleted]         v0.9

要看看是否真的從遠程庫刪除了標籤，可以登陸GitHub查看。

刪除標籤前

刪除標籤後

小結

命令git push origin <tagname>可以推送一個本地標籤；

命令git push origin --tags可以推送全部未推送過的本地標籤；

命令git tag -d <tagname>可以刪除一個本地標籤；

命令git push origin :refs/tags/<tagname>可以刪除一個遠程標籤。

遠程倉庫 & 分支管理&標籤管理

遠程倉庫

添加遠程庫

從遠程庫克隆

分支管理

創建與合併分支

解決衝突

分支管理策略

Bug分支

Feature分支

多人協作

標籤管理

創建標籤

操作標籤

win11關閉自動檢測病毒刪文件

千兆寬帶實際網速能到達多少？

Common issues of disk going full on EMR Cluster (or In general any Hadoop / Spark cluster)

Amazon AWS 中國區的那些"坑"

jedis使用scan替換keys

HDFS中將普通用戶加入到supergroup組來訪問HDFS

hive-site.xml 參數設置

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結