Git學習筆記

時間 2019-11-16

標籤 git 學習筆記欄目 Git 简体版

原文原文鏈接

[TOC]html

Git簡介

描述

Git(讀音爲/gɪt/。)是一個開源的分佈式版本控制系統，能夠有效、高速的處理從很小到很是大的項目版本管理。Git 是 Linus Torvalds 爲了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。linux

Torvalds 開始着手開發 Git 是爲了做爲一種過渡方案來替代 BitKeeper，後者以前一直是 Linux 內核開發人員在全球使用的主要源代碼工具。開放源碼社區中的有些人以爲BitKeeper 的許可證並不適合開放源碼社區的工做，所以 Torvalds 決定着手研究許可證更爲靈活的版本控制系統。儘管最初 Git 的開發是爲了輔助 Linux 內核開發的過程，可是咱們已經發如今不少其餘自由軟件項目中也使用了 Git。例如不少 Freedesktop 的項目遷移到了 Git 上。git

特色

分佈式相比於集中式的最大區別在於開發者能夠提交到本地，每一個開發者經過克隆（git clone），在本地機器上拷貝一個完整的Git倉庫。github

下圖是經典的git開發過程。sql

Git的功能特性：shell

從通常開發者的角度來看，git有如下功能：數據庫

一、從服務器上克隆完整的Git倉庫（包括代碼和版本信息）到單機上。安全

二、在本身的機器上根據不一樣的開發目的，建立分支，修改代碼。服務器

三、在單機上本身建立的分支上提交代碼。網絡

四、在單機上合併分支。

五、把服務器上最新版的代碼fetch下來，而後跟本身的主分支合併。

六、生成補丁（patch），把補丁發送給主開發者。

七、看主開發者的反饋，若是主開發者發現兩個通常開發者之間有衝突（他們之間能夠合做解決的衝突），就會要求他們先解決衝突，而後再由其中一我的提交。若是主開發者能夠本身解決，或者沒有衝突，就經過。

八、通常開發者之間解決衝突的方法，開發者之間能夠使用pull 命令解決衝突，解決完衝突以後再向主開發者提交補丁。

從主開發者的角度（假設主開發者不用開發代碼）看，git有如下功能：

一、查看郵件或者經過其它方式查看通常開發者的提交狀態。

二、打上補丁，解決衝突（能夠本身解決，也能夠要求開發者之間解決之後再從新提交，若是是開源項目，還要決定哪些補丁有用，哪些不用）。

三、向公共服務器提交結果，而後通知全部開發人員。

優勢：

適合分佈式開發，強調個體。

公共服務器壓力和數據量都不會太大。

速度快、靈活。

任意兩個開發者之間能夠很容易的解決衝突。

離線工做。

缺點：

資料少（起碼中文資料不多）。

學習週期相對而言比較長。

不符合常規思惟。

代碼保密性差，一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。

工做流程

通常工做流程以下：

克隆 Git 資源做爲工做目錄。
在克隆的資源上添加或修改文件。
若是其餘人修改了，你能夠更新資源。
在提交前查看修改。
提交修改。
在修改完成後，若是發現錯誤，能夠撤回提交併再次修改並提交。

下圖展現了 Git 的工做流程：

安裝Git

在linux上安裝git

yum -y install git

在mac上安裝git

一是使用homebrew安裝git。

brew install git

二是去git官網下載文件手動安裝。

測試git是否安裝成功

$ git --version
git version 2.16.2

版本庫

建立版本庫

先建立一個空目錄：

$ mkdir gitest
$ cd gitest/
$ pwd
/Users/junxi/gitest

經過git init命令把這個目錄變成能夠管理的倉庫：

$ git init
Initialized empty Git repository in /Users/junxi/gitest/.git/

文件添加到版本庫

編寫一個readme.md文件，內容以下：

Git is a version control system.
Git is free software.

文件必須放在gitest目錄（或其子目錄）下，由於這是一個Git倉庫，在倉庫對應的目錄下才能找到這個文件。

把一個文件放到git倉庫只須要兩步。

第一步，使用命令git add把文件添加到倉庫：

用法：git add file_name1 file_name2 …

git add readme.md

在執行第二步以前能夠使用命令git status查看狀態：

$ git status -s
A  readme.md
$ git status 
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

    new file:   readme.md

第二步，用命令git commit告訴Git，把文件提交到倉庫:

git commit -m "new creating a readme file"

時光穿梭

咱們以前成功地添加並提交了一個readme.md文件，如今嘗試修改一下文件內容：

Git is a distributed version control system.
Git is free software.

如今運行git status命令查看結果：

$ git status
On branch 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.md

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

git status命令可讓咱們時刻掌握倉庫當前的狀態，上面的命令告訴咱們，readme.md被修改過了，但尚未準備提交的修改。

雖然Git告訴咱們readme.md被修改了，可是咱們想看看具體修改了什麼內容。這時候須要用git diff命令查看：

$ git diff readme.md 
diff --git a/readme.md b/readme.md
index 46d49bf..9247db6 100644
--- a/readme.md
+++ b/readme.md
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
 Git is free software.

git diff就是查看差別之處，經過該命令咱們能夠清楚地看到修改了哪些內容，顯示的格式是Unix通用的diff格式。

第二次提交readme.md文件:

$ git add readme.md 

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   readme.md

$ git commit -m "add distributed"
[master b99e891] add distributed
 1 file changed, 1 insertion(+), 1 deletion(-)
 
$ git status
On branch master
nothing to commit, working tree clean

版本回退

再次修改readme.md文件，內容以下：

Git is a distributed version control system.
Git is free software distributed under the GPL.

而後嘗試提交：

$ git add readme.md 
$ git commit -m "append GPL"
[master 49d0f9b] append GPL
 1 file changed, 1 insertion(+), 1 deletion(-)

像這樣，你不斷對文件進行修改，而後不斷提交修改到版本庫裏，就比如玩RPG遊戲時，每經過一關就會自動把遊戲狀態存盤，若是某一關沒過去，你還能夠選擇讀取前一關的狀態。有些時候，在打Boss以前，你會手動存盤，以便萬一打Boss失敗了，能夠從最近的地方從新開始。Git也是同樣，每當你以爲文件修改到必定程度的時候，就能夠「保存一個快照」，這個快照在Git中被稱爲commit。一旦你把文件改亂了，或者誤刪了文件，還能夠從最近的一個commit恢復，而後繼續工做，而不是把幾個月的工做成果所有丟失。

如今，咱們回顧一下readme.md文件一共有幾個版本被提交到Git倉庫裏了：

版本1：new creating a readme file

Git is a version control system.
Git is free software.

版本2：add distributed

Git is a distributed version control system.
Git is free software.

版本3：append GPL

Git is a distributed version control system.
Git is free software distributed under the GPL.

固然了，在實際工做中，咱們腦子裏怎麼可能記得一個幾千行的文件每次都改了什麼內容，否則要版本控制系統幹什麼。版本控制系統確定有某個命令能夠告訴咱們歷史記錄，在Git中，咱們用git log命令查看：

$ git log
commit 49d0f9b9bcf30069a3b0ed91ecf5397738a940e6 (HEAD -> master)
Author: junxi <xinlei3166@126.com>
Date:   Fri Mar 16 15:12:38 2018 +0800

    append GPL

commit b99e891f22fcf8cfcdd3aef737a6b7681b100976
Author: junxi <xinlei3166@126.com>
Date:   Fri Mar 16 14:43:09 2018 +0800

    add distributed

commit f2bc5b8abee58de182cce051b3e0e6d1c7431a22
Author: junxi <xinlei3166@126.com>
Date:   Fri Mar 16 14:04:37 2018 +0800

    new creating a readme file

git log命令顯示從最近到最遠的提交日誌，咱們能夠看到3次提交，最近的一次是append GPL，上一次是add distributed，最先的一次是new creating a readme file。

若是嫌輸出信息太多，看得眼花繚亂的，能夠試試加上--pretty=oneline參數：

$ git log --pretty=oneline
49d0f9b9bcf30069a3b0ed91ecf5397738a940e6 (HEAD -> master) append GPL
b99e891f22fcf8cfcdd3aef737a6b7681b100976 add distributed
f2bc5b8abee58de182cce051b3e0e6d1c7431a22 new creating a readme file

如今咱們啓動時光穿梭機，準備把readme.md回退到上一個版本，也就是「add distributed」的那個版本，怎麼作呢？

首先，Git必須知道當前版本是哪一個版本，在Git中，用HEAD表示當前版本，也就是最新的提交49d0f9b9bcf30069a3b0ed91ecf5397738a940e6（注意個人提交ID和你的確定不同），上一個版本就是HEAD^，上上一個版本就是HEAD^^，固然往上100個版本寫100個^比較容易數不過來，因此寫成HEAD~100。

如今，咱們要把當前版本「append GPL」回退到上一個版本「add distributed」，就能夠使用git reset命令：

$ git reset --hard HEAD^
HEAD is now at b99e891 add distributed

看看readme.md的內容是否是版本add distributed：

junxi-MacBook:gitest junxi$ cat readme.md 
Git is a distributed version control system.
Git is free software.

果真。

還能夠繼續回退到上一個版本wrote a readme file，不過且慢，然咱們用git log再看看如今版本庫的狀態：

$ git log
commit b99e891f22fcf8cfcdd3aef737a6b7681b100976 (HEAD -> master)
Author: junxi <xinlei3166@126.com>
Date:   Fri Mar 16 14:43:09 2018 +0800

    add distributed

commit f2bc5b8abee58de182cce051b3e0e6d1c7431a22
Author: junxi <xinlei3166@126.com>
Date:   Fri Mar 16 14:04:37 2018 +0800

    new creating a readme file

最新的那個版本append GPL已經看不到了！比如你從21世紀坐時光穿梭機來到了19世紀，想再回去已經回不去了，腫麼辦？

辦法其實仍是有的，只要上面的命令行窗口尚未被關掉，你就能夠順着往上找啊找啊，找到那個append GPL的commit id是49d0f9...，因而就能夠指定回到將來的某個版本：

$ git reset --hard 49d0f9
HEAD is now at 49d0f9b append GPL

版本號不必寫全，前幾位就能夠了，Git會自動去找。固然也不能只寫前一兩位，由於Git可能會找到多個版本號，就沒法肯定是哪個了。

再當心翼翼地看看readme.md的內容：

$ cat readme.md 
Git is a distributed version control system.
Git is free software distributed under the GPL.

果真，回到最新了。

Git的版本回退速度很是快，由於Git在內部有個指向當前版本的HEAD指針，當你回退版本的時候，Git僅僅是把HEAD從指向append GPL：

改成指向add distributed：

而後順便把工做區的文件更新了。因此你讓HEAD指向哪一個版本號，你就把當前版本定位在哪。

如今，你回退到了某個版本，關掉了電腦，次日早上就後悔了，想恢復到新版本怎麼辦？找不到新版本的commit id怎麼辦？

在Git中，老是有後悔藥能夠吃的。當你用$ git reset --hard HEAD^回退到add distributed版本時，再想恢復到append GPL，就必須找到append GPL的commit id。Git提供了一個命令git reflog用來記錄你的每一次命令：

$ git reflog
49d0f9b (HEAD -> master) HEAD@{0}: reset: moving to 49d0f9
b99e891 HEAD@{1}: reset: moving to HEAD^
49d0f9b (HEAD -> master) HEAD@{2}: reset: moving to 49d0f9
b99e891 HEAD@{3}: reset: moving to HEAD^
49d0f9b (HEAD -> master) HEAD@{4}: reset: moving to 49d0f9
b99e891 HEAD@{5}: reset: moving to HEAD^
49d0f9b (HEAD -> master) HEAD@{6}: commit: append GPL
b99e891 HEAD@{7}: commit: add distributed
f2bc5b8 HEAD@{8}: commit (initial): new creating a readme file

小結：

HEAD指向的版本就是當前版本，所以，Git容許咱們在版本的歷史之間穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log能夠查看提交歷史，以便肯定要回退到哪一個版本。
要重返將來，用git reflog查看命令歷史，以便肯定要回到將來的哪一個版本。

工做區和暫存區

Git和其餘版本控制系統如SVN的一個不一樣之處就是有暫存區的概念。

工做區（Working Directory）

就是你在電腦裏能看到的目錄，好比個人gitest文件夾就是一個工做區：

版本庫（Repository）

工做區有一個隱藏目錄.git，這個不算工做區，而是Git的版本庫。

Git的版本庫裏存了不少東西，其中最重要的就是稱爲stage（或者叫index）的暫存區，還有Git爲咱們自動建立的第一個分支master，以及指向master的一個指針叫HEAD。

分支和HEAD的概念咱們之後再講。

前面講了咱們把文件往Git版本庫裏添加的時候，是分兩步執行的：

第一步是用git add把文件添加進去，實際上就是把文件修改添加到暫存區；

第二步是用git commit提交更改，實際上就是把暫存區的全部內容提交到當前分支。

由於咱們建立Git版本庫時，Git自動爲咱們建立了惟一一個master分支，因此，如今，git commit就是往master分支上提交更改。

你能夠簡單理解爲，須要提交的文件修改統統放到暫存區，而後，一次性提交暫存區的全部修改。

俗話說，實踐出真知。如今，咱們再練習一遍，先對readme.md作個修改，好比加上一行內容：

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.

而後，在工做區新增一個LICENSE文本文件（內容隨便寫）。

先用git status查看一下狀態：

$ git status
On branch 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.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    LICENSE

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

Git很是清楚地告訴咱們，readme.md被修改了，而LICENSE還歷來沒有被添加過，因此它的狀態是Untracked。

如今，使用兩次命令git add，把readme.md和LICENSE都添加後，用git status再查看一下：

$ git add readme.md LICENSE 
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   LICENSE
    modified:   readme.md

如今，暫存區的狀態就變成這樣了：

因此，git add命令實際上就是把要提交的全部修改放到暫存區（Stage），而後，執行git commit就能夠一次性把暫存區的全部修改提交到分支。

$ git commit -m "understand how stage works"
[master 81673ab] understand how stage works
 2 files changed, 2 insertions(+)
 create mode 100644 LICENSE

一旦提交後，若是你又沒有對工做區作任何修改，那麼工做區就是「乾淨」的：

$ git status
On branch master
nothing to commit, working tree clean

如今版本庫變成了這樣，暫存區就沒有任何內容了：

小結：

暫存區是Git很是重要的概念，弄明白了暫存區，就弄明白了Git的不少操做到底幹了什麼。

沒弄明白暫存區是怎麼回事的童鞋，請向上滾動頁面，再看一次。

管理修改

如今，假定你已經徹底掌握了暫存區的概念。下面，咱們要討論的就是，爲何Git比其餘版本控制系統設計得優秀，由於Git跟蹤並管理的是修改，而非文件。

你會問，什麼是修改？好比你新增了一行，這就是一個修改，刪除了一行，也是一個修改，更改了某些字符，也是一個修改，刪了一些又加了一些，也是一個修改，甚至建立一個新文件，也算一個修改。

爲何說Git管理的是修改，而不是文件呢？咱們仍是作實驗。第一步，對readme.md作一個修改，好比加一行內容：

$ cat readme.md 
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.

而後添加：

$ git add readme.md 
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   readme.md

而後，再修改readme.md：

$ cat readme.md 
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.

提交：

$ git commit -m "git tracks changes"
[master fd42bc4] git tracks changes
 1 file changed, 1 insertion(+)

提交後，再看看狀態：

$ git status
On branch 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.md

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

咦，怎麼第二次的修改沒有被提交？

別激動，咱們回顧一下操做過程：

第一次修改 -> git add -> 第二次修改 -> git commit

你看，咱們前面講了，Git管理的是修改，當你用git add命令後，在工做區的第一次修改被放入暫存區，準備提交，可是，在工做區的第二次修改並無放入暫存區，因此，git commit只負責把暫存區的修改提交了，也就是第一次的修改被提交了，第二次的修改不會被提交。

提交後，用git diff HEAD -- readme.md命令能夠查看工做區和版本庫裏面最新版本的區別：

$ git diff HEAD -- readme.md 
diff --git a/readme.md b/readme.md
index 76d770f..a9c5755 100644
--- a/readme.md
+++ b/readme.md
@@ -1,4 +1,4 @@
 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.
+Git tracks changes of files.

可見，第二次修改確實沒有被提交。

那怎麼提交第二次修改呢？你能夠繼續git add再git commit，也能夠彆着急提交第一次修改，先git add第二次修改，再git commit，就至關於把兩次修改合併後一塊提交了：

第一次修改 -> git add -> 第二次修改 -> git add -> git commit

好，如今，把第二次修改提交了，而後開始小結。

小結：

如今，你又理解了Git是如何跟蹤修改的，每次修改，若是不add到暫存區，那就不會加入到commit中。

撤銷修改

天然，你是不會犯錯的。不過如今是凌晨兩點，你正在趕一份工做報告，你在readme.md中添加了一行：

$ cat readme.md 
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.
My stupid boss still prefers SVN.

在你準備提交前，一杯咖啡起了做用，你猛然發現了「stupid boss」可能會讓你丟掉這個月的獎金！

既然錯誤發現得很及時，就能夠很容易地糾正它。你能夠刪掉最後一行，手動把文件恢復到上一個版本的狀態。若是用git status查看一下：

$ git status
On branch 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.md

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

你能夠發現，Git會告訴你，git checkout -- file能夠丟棄工做區的修改：

$ git checkout -- readme.md

命令git checkout -- readme.md意思就是，把readme.md文件在工做區的修改所有撤銷，這裏有兩種狀況：

一種是readme.md自修改後尚未被放到暫存區，如今，撤銷修改就回到和版本庫如出一轍的狀態；

一種是readme.md已經添加到暫存區後，又做了修改，如今，撤銷修改就回到添加到暫存區後的狀態。

總之，就是讓這個文件回到最近一次git commit或git add時的狀態。

如今，看看readme.md的文件內容：

$ cat readme.md 
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.

文件內容果真復原了。

git checkout -- file命令中的--很重要，沒有--，就變成了「切換到另外一個分支」的命令，咱們在後面的分支管理中會再次遇到git checkout命令。

如今假定是凌晨3點，你不但寫了一些胡話，還git add到暫存區了：

$ cat readme.md 
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.
My stupid boss still prefers SVN.
$ git add readme.md

慶幸的是，在commit以前，你發現了這個問題。用git status查看一下，修改只是添加到了暫存區，尚未提交：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   readme.md

Git一樣告訴咱們，用命令git reset HEAD file能夠把暫存區的修改撤銷掉（unstage），從新放回工做區：

$ git reset HEAD readme.md 
Unstaged changes after reset:
M    readme.md

git reset命令既能夠回退版本，也能夠把暫存區的修改回退到工做區。當咱們用HEAD時，表示最新的版本。

再用git status查看一下，如今暫存區是乾淨的，工做區有修改：

$ git status
On branch 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.md

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

還記得如何丟棄工做區的修改嗎？

$ git checkout -- readme.md
$ git status
On branch master
nothing to commit, working tree clean
$ cat readme.md 
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks change

ok.

如今，假設你不但改錯了東西，還從暫存區提交到了版本庫，怎麼辦呢？還記得版本回退一節嗎？能夠回退到上一個版本。不過，這是有條件的，就是你尚未把本身的本地版本庫推送到遠程。還記得Git是分佈式版本控制系統嗎？咱們後面會講到遠程版本庫，一旦你把「stupid boss」提交推送到遠程版本庫，你就真的慘了……

小結

場景1：當你改亂了工做區某個文件的內容，想直接丟棄工做區的修改時，用命令git checkout -- file。

場景2：當你不但改亂了工做區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD file，就回到了場景1，第二步按場景1操做。

場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫。

刪除文件

在Git中，刪除也是一個修改操做，咱們實戰一下，先添加一個新文件test.txt到Git而且提交：

$ cat test.txt 
new createing a test.txt file.

$ git add test.txt 
$ git commit -m "add test.txt"
[master 6aade49] add test.txt
 1 file changed, 2 insertions(+)
 create mode 100644 test.txt

通常狀況下，你一般直接在文件管理器中把沒用的文件刪了，或者用rm命令刪了：

$ rm test.txt

這個時候，Git知道你刪除了文件，所以，工做區和版本庫就不一致了，git status命令會馬上告訴你哪些文件被刪除了：

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    test.txt

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

如今你有兩個選擇，一是確實要從版本庫中刪除該文件，那就用命令git rm刪掉，而且git commit：

$ git rm test.txt
rm 'test.txt'
$ git commit -m "remove test.txt"
[master 3f1febc] remove test.txt
 1 file changed, 2 deletions(-)
 delete mode 100644 test.txt

如今，文件就從版本庫中被刪除了。

另外一種狀況是刪錯了，由於版本庫裏還有呢，因此能夠很輕鬆地把誤刪的文件恢復到最新版本：

$ git checkout -- test.txt

git checkout實際上是用版本庫裏的版本替換工做區的版本，不管工做區是修改仍是刪除，均可以「一鍵還原」。

小結

命令git rm用於刪除一個文件。若是一個文件已經被提交到版本庫，那麼你永遠不用擔憂誤刪，可是要當心，你只能恢復文件到最新版本，你會丟失最近一次提交後你修改的內容。

遠程倉庫

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

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

沒錯，若是隻是在一個倉庫裏管理文件歷史，Git和SVN真沒啥區別。爲了保證你如今所學的Git物超所值，未來絕對不會後悔，本章開始介紹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 "xxx@126.com"
$ ll ~/.ssh/
total 56
-rw-------  1 junxi  staff  1679 12 11 09:51 id_rsa
-rw-r--r--  1 junxi  staff   396 12 11 09:51 id_rsa.pub

若是一切順利的話，能夠在用戶主目錄裏找到.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文件的內容：

點「Add Key」，你就應該看到已經添加的Key：

爲何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，而後，在右上角找到「Create a new repo」按鈕，建立一個新的倉庫：

在Repository name填入gitest，其餘保持默認設置，點擊「Create repository」按鈕，就成功地建立了一個新的Git倉庫：

目前，在GitHub上的這個gitest倉庫仍是空的，GitHub告訴咱們，能夠從這個倉庫克隆出新的倉庫，也能夠把一個已有的本地倉庫與之關聯，而後，把本地倉庫的內容推送到GitHub倉庫。

如今，咱們根據GitHub的提示，在本地的gitest倉庫下運行命令：

$ pwd
/Users/junxi/gitest
$ git remote add origin git@github.com:junxi3166/gitest.git

請千萬注意，把上面的junxi3166替換成你本身的GitHub帳戶名，不然，你在本地關聯的就是個人遠程庫，關聯沒有問題，可是你之後推送是推不上去的，由於你的SSH Key公鑰不在個人帳戶列表中。

添加後，遠程庫的名字就是origin，這是Git默認的叫法，也能夠改爲別的，可是origin這個名字一看就知道是遠程庫。

下一步，就能夠把本地庫的全部內容推送到遠程庫上：

$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.63 KiB | 837.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.

To github.com:junxi3166/gitest.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 (13.250.177.223)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
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,13.250.177.223' (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文件：

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

$ git clone git@github.com:junxi3166/gitskills.git
Cloning into 'gitskills'...
Warning: Permanently added the RSA host key for IP address '13.229.188.59' 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/junxi3166/gitskills.git這樣的地址。實際上，Git支持多種協議，默認的git://使用ssh，但也能夠使用https等其餘協議。

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

小結

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

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

分支管理

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

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

分支在實際中有什麼用呢？假設你準備開發一個新功能，可是須要兩週才能完成，第一週你寫了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上：

你看，Git建立一個分支很快，由於除了增長一個dev指針，改改HEAD的指向，工做區的文件都沒有任何變化！

不過，從如今開始，對工做區的修改和提交就是針對dev分支了，好比新提交一次後，dev指針往前移動一步，而master指針不變：

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

因此Git合併分支也很快！就改改指針，工做區內容也不變！

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

真是太神奇了，你看得出來有些提交是經過分支完成的嗎？

下面開始實戰。

首先，咱們建立dev分支，而後切換到dev分支：

$ pwd
/Users/junxi/gitskills
$ 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.md作個修改，加上一行：

Creating a new branch is quick.

而後提交：

$ git add README.md 
$ git commit -m "branch test"
[dev be2e7c9] branch test
 1 file changed, 1 insertion(+)

如今，dev分支的工做完成，咱們就能夠切換回master分支：

$ git checkout master
Switched to branch 'master'

切換回master分支後，再查看一下README.md文件，剛纔添加的內容不見了！由於那個提交是在dev分支上，而master分支此刻的提交點並無變：

$ cat README.md 
# gitskills
gitskills

如今，咱們把dev分支的工做成果合併到master分支上：

$ git merge dev
Updating 09f920d..be2e7c9
Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)

git merge命令用於合併指定分支到當前分支。合併後，再查看README.md 的內容，就能夠看到，和dev分支的最新提交是徹底同樣的。

$ cat README.md 
# gitskills
gitskills
Creating a new branch is quick.

注意到上面的Fast-forward信息，Git告訴咱們，此次合併是「快進模式」，也就是直接把master指向dev的當前提交，因此合併速度很是快。

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

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

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

刪除後，查看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 3a8b438] 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.md文件的最後一行改成：

Creating a new branch is quick & simple.

提交：

$ git add README.md 
$ git commit -m "& simple"
[master 23307ae] & 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
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 5f3dff6] conflict fixed

如今，master分支和feature1分支變成了下圖所示：

用帶參數的git log也能夠看到分支的合併狀況：

$ git log --graph --pretty=oneline --abbrev-commit
*   5f3dff6 (HEAD -> master) conflict fixed
|\  
| * 3a8b438 (feature1) AND simple
* | 23307ae & simple
|/  
* be2e7c9 branch test
* 09f920d (origin/master, origin/HEAD) Initial commit

最後，刪除feature1分支：

$ git branch -d feature1
Deleted branch feature1 (was 3a8b438).

完成。

小結

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

用git log --graph命令能夠看到分支合併圖。

分支管理策略

一般，合併分支時，若是可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支信息。

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

下面咱們實戰一下--no-ff方式的git merge：

首先，仍然建立並切換dev分支：

$ git checkout -b dev

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

$ # vi README.md 
$ git add README.md
$ git commit -m "fenzhi."

如今，咱們切換回master：

$ git checkout master

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

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

由於本次合併要建立一個新的commit，因此加上-m參數，把commit描述寫進去。

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

$ git log --graph --pretty=oneline --abbrev-commit
*   535190d (HEAD -> master) merge with no-ff
|\  
| * c5e8566 (dev) fenzhi.
|/  
*   5f3dff6 conflict fixed
|\  
| * 3a8b438 AND simple
* | 23307ae & simple
|/  
* be2e7c9 branch test
* 09f920d (origin/master, origin/HEAD) Initial commit

能夠看到，不使用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 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.md

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

幸虧，Git還提供了一個stash功能，能夠把當前工做現場「儲藏」起來，等之後恢復現場後繼續工做：

$ git stash
Saved working directory and index state WIP on dev: 6224937 add merge
HEAD is now at 6224937 add merge

如今，用git status查看工做區，就是乾淨的（除非有沒有被Git管理的文件），所以能夠放心地建立分支來修復bug。

首先肯定要在哪一個分支上修復bug，假定須要在master分支上修復，就從master建立臨時分支：

$ git checkout master
Already on '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，須要把「gitskills」改成「GITSKILLS」，而後提交：

$ git add README.md 
$ git commit -m "fix bug 101"
[issue-101 966ad32] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

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

$ git checkout master
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 "merge bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-101
Deleted branch issue-101 (was 966ad32)

太棒了，原計劃兩個小時的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.md
#
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

5分鐘後，開發完畢：

$ 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 0c7a1a3] add feature vulcan
 1 file changed, 1 insertion(+)
 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 0c7a1a3).

終於刪除成功！

小結

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

若是要丟棄一個沒有被合併過的分支，能夠經過git branch -D <name>強行刪除。

多人協做

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

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

$ git remote
origin

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

$ git remote -v
origin    git@github.com:junxi3166/gitskills.git (fetch)
origin    git@github.com:junxi3166/gitskills.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 git@github.com:junxi3166/gitskills.git skills
Cloning into 'skills'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
$ cd skills/
$ git remote -v
origin    git@github.com:junxi3166/gitskills.git (fetch)
origin    git@github.com:junxi3166/gitskills.git (push)

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

$ git branch
* master

如今，你的小夥伴要在dev分支上開發，就必須建立遠程origin的dev分支到本地，因而他用這個命令建立本地dev分支：

$ git checkout -b dev

如今，他就能夠在dev上繼續修改，而後，時不時地把dev分支push到遠程：

$ # vi hello.py
$ git add hello.py 
$ git commit -m "add two hello"
[dev 5bd8a63] add two hello
 1 file changed, 1 insertion(+)
 create mode 100644 hello.py
$ git push origin dev
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 280 bytes | 280.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:junxi3166/gitskills.git
 * [new branch]      dev -> dev

你的小夥伴已經向origin/dev分支推送了他的提交，而碰巧你也對一樣的文件做了修改，並試圖推送：

$ # vi hello.py
$ git add hello.py 
$ git commit -m "add coding: _*_ utf-8 _*_"
[dev 003e6ed] add coding: _*_ utf-8 _*_
 1 file changed, 1 insertion(+)
 create mode 100644 hello.py
$ git push origin dev
To github.com:junxi3166/gitskills.git
 ! [rejected]        dev -> dev (fetch first)
error: failed to push some refs to 'git@github.com:junxi3166/gitskills.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.

推送失敗，由於你的小夥伴的最新提交和你試圖推送的提交有衝突，解決辦法也很簡單，Git已經提示咱們，先用git pull把最新的提交從origin/dev抓下來，而後，在本地合併，解決衝突，再推送：

$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:junxi3166/gitskills
 * [new branch]      ddd        -> origin/ddd
 * [new branch]      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-to=origin/<branch> dev

git pull也失敗了，緣由是沒有指定本地dev分支與遠程origin/dev分支的連接，根據提示，設置dev和origin/dev的連接：

$ git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.

再pull：

$ git pull
Auto-merging hello.py
CONFLICT (add/add): Merge conflict in hello.py
Automatic merge failed; fix conflicts and then commit the result.

這回git pull成功，可是合併有衝突，須要手動解決，解決的方法和分支管理中的解決衝突徹底同樣。解決後，提交，再push：

$ # vi hello.py 
$ git add hello.py 
$ git commit -m "merge & fix hello.py"
[dev ac35808] merge & fix hello.py
$ git push origin dev
Counting objects: 21, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (21/21), 1.75 KiB | 1.75 MiB/s, done.
Total 21 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), done.
To github.com:junxi3166/gitskills.git
   5bd8a63..ac35808  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
4fef11f (HEAD -> master, tag: v1.0) merge bug fix 101
966ad32 fix bug 101
535190d merge with no-ff
c5e8566 fenzhi.
5f3dff6 conflict fixed
23307ae & simple
3a8b438 AND simple
be2e7c9 branch test
09f920d (origin/master, origin/ddd, origin/HEAD) Initial commit

比方說要對fenzhi.此次提交打標籤，它對應的commit id是c5e8566，敲入命令：

$ git tag v0.9 c5e8566

再用命令git tag查看標籤：

$ git tag
v0.9
v1.0

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

$ git show v0.9
commit c5e8566a61a1c889dc3a56f685eaf97dc9b1c2fe (tag: v0.9)
Author: junxi <xinlei3166@126.com>
Date:   Mon Mar 19 15:42:34 2018 +0800

    fenzhi.

diff --git a/README.md b/README.md
index 6e05639..b565a7f 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
 # gitskills
 gitskills
 Creating a new branch is quick and simple.
+fenzhi.

能夠看到，v0.9確實打在fenzhi.此次提交上。

還能夠建立帶有說明的標籤，用-a指定標籤名，-m指定說明文字：

$ git tag -a v0.1 -m "version 0.1" 09f920d

用命令git show <tagname>能夠看到說明文字：

$ git show v0.1
tag v0.1
Tagger: junxi <xinlei3166@126.com>
Date:   Tue Mar 20 10:19:47 2018 +0800

version 0.1

commit 09f920d5df09b29d762ab839b516dde1339c36e0 (tag: v0.1, origin/master, origin/ddd, origin/HEAD)
Author: junxi <xinlei3166@126.com>
Date:   Mon Mar 19 14:28:02 2018 +0800

    Initial commit

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..7f15fca
--- /dev/null
+++ b/README.md
@@ -0,0 +1,2 @@
+# gitskills
+gitskills

還能夠經過-s用私鑰簽名一個標籤：

$ git tag -s v0.2 -m "version 0.2" be2e7c9

簽名採用PGP簽名，所以，必須首先安裝gpg（GnuPG），若是沒有找到gpg，或者沒有gpg密鑰對，就會報錯：

fatal: cannot run gpg: No such file or directory
error: gpg failed to sign the data
error: unable to sign the tag

若是報錯，請參考GnuPG幫助文檔配置Key。

$ brew install gnupg
$ gpg --gen-key
$ gpg --list-keys
$ gpg --list-secret-keys
$ git config --global user.signingkey <GPG-key-id>

用命令git show <tagname>能夠看到PGP簽名信息：

$ git show v0.2

小結

命令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

由於建立的標籤都只存儲在本地，不會自動推送到遠程。因此，打錯的標籤能夠在本地安全刪除。

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

$ git push origin v1.0

或者，一次性推送所有還沒有推送到遠程的本地標籤：

$ git push origin --tags

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

$ git tag -d v0.9

而後，從遠程刪除。刪除命令也是push，可是格式以下：

$ git push origin :refs/tags/v0.9

要看看是否真的從遠程庫刪除了標籤，能夠登錄GitHub查看。

小結

命令git push origin <tagname>能夠推送一個本地標籤；
命令git push origin --tags能夠推送所有未推送過的本地標籤；
命令git tag -d <tagname>能夠刪除一個本地標籤；
命令git push origin :refs/tags/<tagname>能夠刪除一個遠程標籤。

自定義Git

在安裝Git一節中，咱們已經配置了user.name和user.email，實際上，Git還有不少可配置項。

好比，讓Git顯示顏色，會讓命令輸出看起來更醒目：

Git忽略文件

有些時候，你必須把某些文件放到Git工做目錄中，但又不能提交它們，好比保存了數據庫密碼的配置文件啦，等等，每次git status都會顯示Untracked files ...，有強迫症的童鞋內心確定不爽。

好在Git考慮到了你們的感覺，這個問題解決起來也很簡單，在Git工做區的根目錄下建立一個特殊的.gitignore文件，而後把要忽略的文件名填進去，Git就會自動忽略這些文件。

不須要從頭寫.gitignore文件，GitHub已經爲咱們準備了各類配置文件，只須要組合一下就能夠使用了。全部配置文件能夠直接在線瀏覽：https://github.com/github/git...

忽略文件的原則是：

忽略操做系統自動生成的文件，好比縮略圖等；
忽略編譯生成的中間文件、可執行文件等，也就是若是一個文件是經過另外一個文件自動生成的，那自動生成的文件就不必放進版本庫，好比Java編譯產生的.class文件；
忽略你本身的帶有敏感信息的配置文件，好比存放口令的配置文件。

例子：

忽略Python編譯產生的.pyc、.pyo、dist等文件或目錄：

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

加上你本身定義的文件，最終獲得一個完整的.gitignore文件，內容以下：

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
*$py.class
dist
build
__pycache__
migrations
!migrations/__init__.py


# Translations
*.mo
*.pot

# Django stuff:
*.log
local_settings.py
db.sqlite3

# Jupyter Notebook
.ipynb_checkpoints
# Pycharm
.idea

最後一步就是把.gitignore也提交到Git，就完成了！固然檢驗.gitignore的標準是git status命令是否是說working directory clean。

有些時候，你想添加一個文件到Git，但發現添加不了，緣由是這個文件被.gitignore忽略了：

$ git add hello.pyc
The following paths are ignored by one of your .gitignore files:
hello.pyc
Use -f if you really want to add them.

若是你確實想添加該文件，能夠用-f強制添加到Git：

$ git add -f hello.pyc

或者你發現，多是.gitignore寫得有問題，須要找出來到底哪一個規則寫錯了，能夠用git check-ignore命令檢查：

$ git check-ignore -v hello.pyc
.gitignore:2:*.py[cod]    hello.pyc

Git會告訴咱們，.gitignore的第3行規則忽略了該文件，因而咱們就能夠知道應該修訂哪一個規則。

小結

忽略某些文件時，須要編寫.gitignore；
.gitignore文件自己要放到版本庫裏，而且能夠對.gitignore作版本管理！

配置別名

有沒有常常敲錯命令？好比git status？status這個單詞真心很差記。

若是敲git st就表示git status那就簡單多了，固然這種偷懶的辦法咱們是極力同意的。

咱們只須要敲一行命令，告訴Git，之後st就表示status：

$ git config --global alias.st status

好了，如今敲git st看看效果。

固然還有別的命令能夠簡寫，不少人都用co表示checkout，ci表示commit，br表示branch：

$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch

之後提交就能夠簡寫成：

$ git ci -m "bala bala bala..."

--global參數是全局參數，也就是這些命令在這臺電腦的全部Git倉庫下都有用。

在撤銷修改一節中，咱們知道，命令git reset HEAD file能夠把暫存區的修改撤銷掉（unstage），從新放回工做區。既然是一個unstage操做，就能夠配置一個unstage別名：

$ git config --global alias.unstage 'reset HEAD'

當你敲入命令：

$ git unstage test.py

實際上Git執行的是：

$ git reset HEAD test.py

配置一個git last，讓其顯示最後一次提交信息：

$ git config --global alias.last 'log -1'

這樣，用git last就能顯示最近一次的提交：

$ git last
commit ac358082b6694ba923c293828a54b4115c6efcb0 (HEAD -> dev, origin/dev)
Merge: 003e6ed 5bd8a63
Author: junxi <xinlei3166@126.com>
Date:   Mon Mar 19 17:21:02 2018 +0800

    merge & fix hello.py

甚至還有人喪心病狂地把lg配置成了：

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

來看看git lg的效果：

爲何不早點告訴我？別激動，咱不是爲了多記幾個英文單詞嘛！

配置文件

配置Git的時候，加上--global是針對當前用戶起做用的，若是不加，那隻針對當前的倉庫起做用。

配置文件放哪了？每一個倉庫的Git配置文件都放在.git/config文件中：

$ pwd
/Users/junxi/gitskills
$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
    url = git@github.com:junxi3166/gitskills.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[branch "dev"]
    remote = origin
    merge = refs/heads/dev

別名就在[alias]後面，要刪除別名，直接把對應的行刪掉便可。

而當前用戶的Git配置文件放在用戶主目錄下的一個隱藏文件.gitconfig中：

$ cat ~/.gitconfig 
[user]
    email = xxx@126.com
    name = junxi
    signingkey = 4776DFA6E0FEBB24F9A70A49C722C757D7AF8BF3
[color]
    ui = true
[core]
    autocrlf = input
[filter "lfs"]
    clean = git-lfs clean -- %f
    smudge = git-lfs smudge -- %f
    process = git-lfs filter-process
    required = true
[alias]
    st = status
    last = log -1
    lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

配置別名也能夠直接修改這個文件，若是改錯了，能夠刪掉文件從新經過命令配置。

小結

給Git配置好別名，就能夠輸入命令時偷個懶。咱們鼓勵偷懶。