Git命令學習筆記

1. 安裝 Github


查看是否安裝git:

$ git
The program ‘git’ is currently not installed. 
You can install it by typing: sudo apt-get install git```
安裝git命令:**sudo apt-get install git**

安裝完成后,還需要最后一步設置,在命令行輸入:

$ git config --global user.name "Your Name"
$ git config --global user.email "[email@example.com]"

>因為Git是分布式版本控制系統,所以,每個機器都必須自報家門:你的名字和Email地址。你也許會擔心,如果有人故意冒充別人怎么辦?這個不必擔心,首先我們相信大家都是善良無知的群眾,其次,真的有冒充的也是有辦法可查的。

注意git config 命令的--global參數,用了這個參數,表示你這臺機器上所有的Git倉庫都會使用這個配置,當然也可以對某個倉庫指定不同的用戶名和Email地址。

####2. 創建版本庫
***
創建一個版本庫非常簡單,首先,選擇一個合適的地方,創建一個空目錄:

$ mkdir learngit
$ cd learngit
$git init
Initialized empty Git repository in /Users/michael/learngit/.git/

瞬間Git就把倉庫建好了,而且告訴你是一個空的倉庫(empty Git repository),細心的讀者可以發現當前目錄下多了一個.git的目錄,這個目錄是Git來跟蹤管理版本庫的,沒事千萬不要手動修改這個目錄里面的文件,不然改亂了,就把Git倉庫給破壞了。

####3. 把文件添加到版本庫
***
首先這里再明確一下,所有的版本控制系統,其實只能跟蹤文本文件的改動,比如TXT文件,網頁,所有的程序代碼等等,Git也不例外。

版本控制系統可以告訴你每次的改動,比如在第5行加了一個單詞“Linux”,在第8行刪了一個單詞“Windows”。而圖片、視頻這些二進制文件,雖然也能由版本控制系統管理,但沒法跟蹤文件的變化,只能把二進制文件每次改動串起來,也就是只知道圖片從100KB改成了120KB,但到底改了啥,版本控制系統不知道,也沒法知道。

不幸的是,Microsoft的Word格式是二進制格式,因此,版本控制系統是沒法跟蹤Word文件的改動的,前面我們舉的例子只是為了演示,如果要真正使用版本控制系統,就要以純文本方式編寫文件。

現在我們編寫一個readme.txt文件,內容如下:
>Git is a version control system. Git is free software.

一定要放到learngit目錄下(子目錄也行),因為這是一個Git倉庫,放到其他地方Git再厲害也找不到這個文件。

把一個文件放到Git倉庫只需要兩步:
**第一步**,用命令**git add**告訴Git,把文件添加到倉庫:

$ git add readme.txt```
執行上面的命令,沒有任何顯示,這就對了,Unix的哲學是“沒有消息就是好消息”,說明添加成功。
第二步,用命令git commit告訴Git,把文件提交到倉庫:

$  git  commit -m  "wrote a readme file"
[master (root-commit) cb926e7] wrote a readme file 1 file changed, 2 insertions(+)
create mode 100644 readme.txt```
簡單解釋一下**git commit**命令: **-m**后面輸入的是本次提交的說明,可以輸入任意內容,當然最好是有意義的,這樣你就能從歷史記錄里方便地找到改動記錄。

**git commit**命令執行成功后會告訴你,1個文件被改動(我們新添加的readme.txt文件),插入了兩行內容(readme.txt有兩行內容)。

為什么Git添加文件需要add,commit一共兩步呢?
因為commit可以一次提交很多文件,所以你可以多次add不同的文件,比如:

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."```
git status
命令可以讓我們時刻掌握倉庫當前的狀態,上面的命令告訴我們,readme.txt被修改過了,但還沒有準備提交的修改。

$ git status 
#On branch master 
# Changes not staged for commit:     ----------add之前,變化還沒進入暫存區;
#   (use "git add ..." to update what will be committed) 
#   (use "git checkout -- ..." to discard changes in working directory) 
#       modified:   readme.txt  ---此文件被修改
# 
# Untracked files:  -----此文件是新的,以前從未被提交過;
#   (use "git add ..." to include in what will be committed)
#       LICENSE

雖然Git告訴我們readme.txt被修改了,但如果能看看具體修改了什么內容,自然是很好的。
比如你休假兩周從國外回來,第一天上班時,已經記不清上次怎么修改的readme.txt,所以,需要用git diff這個命令看看。

git diff顧名思義就是查看difference,顯示的格式正是Unix通用的diff格式。

$  git diff readme.txt 
diff –git a/readme.txt b/readme.txt 
index 46d49bf..9247db6 100644 — a/readme.txt +++ b/readme.txt
 @@ -1,2 +1,2 @@ -Git is a version control system. –這一句沒了 
+Git is a distributed version control system. — 這一句是新加的 Git is free software. –這一句是原來就有的```
先把大量文件一次性add進來:**git  add  *.py**,然后你用**git status**查看,會有提示:

$git status
Changes to be committed:
(use "git reset HEAD ..." to unstage)
new file: 1.py
new file: 2.py
new file: 3.py
new file: 4.py

要排除掉其中一個文件,用:**git reset HEAD 1.py**
這時再用`git status`看,1.py變成了**untracked**,剩下的就可以提交了。

####4,版本回退
***
*在實際工作中,我們腦子里怎么可能記得一個幾千行的文件每次都改了什么內容,不然要版本控制系統干什么。*

版本控制系統肯定有某個命令可以告訴我們歷史記錄,在Git中,我們用**git log**命令查看;
git log命令顯示從最近到最遠的提交日志,我們可以看到3次提交,最近的一次是append GPL,上一次是add distributed,最早的一次是wrote a readme file。

首先,Git必須知道當前版本是哪個版本,在Git中,用HEAD表示當前版本,也就是最新的提交3628164...882e1e0(注意:我的提交ID和你的肯不一在Git中),上一個版本就是HEAD^,上上一個版本就是HEAD^^,當然往上100個版本寫100個^比較容易數不過來,所以寫成HEAD~100。

現在,我們要把當前版本“append GPL”回退到上一個版本“add distributed”,就可以使用git reset
命令:

$ git re****set--hard HEAD^
HEAD is now at ea34578 add distributed

`$ cat readme.txt`   查看當前版本下,文件的內容; 
>Git is a distributed version control system. Git is free software.

然我們用**git log**再看看現在版本庫的狀態:最新的那個版本append GPL已經看不到了;
想再回去已經回不去了,腫么辦?辦法其實還是有的,只要上面的命令行窗口還沒有被關掉,你就可以順著往上找啊找啊,找到那個append GPL的commit id是3628164...,于是就可以指定回到未來的某個版本:

$ git re set --hard 3628164**
HEAD is now at 3628164 append GPL

版本號沒必要寫全,前幾位就可以了,Git會自動去找。當然也不能只寫前一兩位,因為Git可能會找到多個版本號,就無法確定是哪一個了。
在Git中,總是有后悔藥可以吃的。當你用`$ git reset --hard HEAD^`
回退到`add distributed`版本時,再想恢復到`append GPL`,就必須找到`append GPL`的**commit id**。Git提供了一個命令git reflog用來記錄你的每一次命令:$ **git reflog**

$ git reflog
ea34578 HEAD@{0}: reset: moving to HEAD^3628164
HEAD@{1}: commit: append GPLea34578
HEAD@{2}: commit: add distributedcb926e7
HEAD@{3}: commit (initial): wrote a readme file

####5. 工作區和暫存區
***
>Git和其他版本控制系統如SVN的一個不同之處就是有暫存區的概念。

先來看名詞解釋:
**工作區(Working Directory)**就是你在電腦里能看到的目錄,比如我的syzgit文件夾就是一個工作區.
**版本庫(Repository)**工作區有一個隱藏目錄.git,這個不算工作區,而是Git的版本庫。
Git的版本庫里存了很多東西,其中最重要的就是稱為**stage(或者叫index)的暫存區**,還有Git為我們自動創建的**第一個分支master**,以及指向master的一個指針叫**HEAD**。
![git-repo](http://upload-images.jianshu.io/upload_images/220694-211fe3d4378c607d?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
分支和HEAD的概念我們以后再講。前面講了我們把文件往Git版本庫里添加的時候,是分兩步執行的:
**第一步**是用**git add**  --> 把文件添加進去,實際上就是把文件修改添加到暫存區
**第二步**是用**git commit**  --> 提交更改,實際上就是把暫存區的所有內容提交到當前分支。

因為我們創建Git版本庫時,Git自動為我們創建了唯一一個master分支,所以,現在,**git commit**就是往**master**分支上提交更改。你可以簡單理解為,需要提交的文件修改通通放到暫存區,然后,一次性提交暫存區的所有修改。
####6,管理修改,撤銷修改,刪除文件
***
>為什么Git比其他版本控制系統設計得優秀,因為**Git跟蹤并管理的是修改,而非文件**。

你會問,什么是修改?
*比如你新增了一行,這就是一個修改,刪除了一行,也是一個修改,更改了某些字符,也是一個修改,刪了一些又加了一些,也是一個修改,甚至創建一個新文件,也算一個修改。*

**Git管理的是修改**,當你用**git add**命令后,在工作區的第一次修改被放入暫存區,準備提交,但是文件又被修改一次,在工作區的第二次修改并沒有放入暫存區,所以此時直接用**git commit**只負責把暫存區的修改提交了,也就是第一次的修改被提交了,第二次的修改不會被提交。

那怎么提交第二次修改呢?你可以繼續**git add**再**git commit**,也可以別著急提交第一次修改,先**git add**第二次修改,再**git commit**,就相當于把兩次修改合并后一塊提交了:
>第一次修改 -> git add-> 第二次修改 -> git add -> git commit

$ git status

On branch master

Changes not staged for commit: --- add之前

(use "git add ..." to update what will be committed)

(use "git checkout -- ..." to discard changes in working directory)

# modified: readme.txt

Git會告訴你,**git checkout -- file** 可以丟棄工作區的修改:
>**$ git checkout **--** readme.txt    撤銷工作區的修改  回到  暫存區/庫版本**

命令**git checkout -- readme.txt**意思就是,把readme.txt文件在**工作區的修改全部撤銷**,
>這里有兩種情況:
   一種是readme.txt自修改后還沒有被放到暫存區,現在,撤銷修改就回到和版本庫一模一樣的狀態;
   一種是readme.txt已經添加到暫存區后,又作了修改,現在,撤銷修改就回到添加到暫存區后的狀態。

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

**git checkout -- file**命令中的**--**很重要,沒有--,就變成了“創建一個新分支”的命令,我們在后面的分支管理中會再次遇到**git checkout**命令。

Git同樣告訴我們,用命令**git reset HEAD file**,**撤銷暫存區的修改掉(unstage),重新放回工作區**
**git reset**命令既可以回退版本,也可以把暫存區的修改回退到工作區。當我們用HEAD時表示最新的版本。
>場景1:當你改亂了工作區某個文件的內容,想直接丟棄工作區的修改時,用命令git checkout -- file。
場景2:當你不但改亂了工作區某個文件的內容,還添加到了暫存區時,想丟棄修改,分兩步,第一步用命令git reset HEAD file,就回到了場景1,第二步按場景1操作。
場景3:已經提交了不合適的修改到版本庫時,想要撤銷本次提交,參考[版本回退](http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013744142037508cf42e51debf49668810645e02887691000)一節,不過前提是沒有推送到遠程庫。

Git知道你刪除了文件,因此,工作區和版本庫就不一致了,**git status**
命令會立刻告訴你哪些文件被刪除了:

$ git status

On branch master

Changes not staged for commit:

(use "git add/rm ..." to update what will be committed)

(use "git checkout -- ..." 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
$ git commit -m "remove test.txt"
[master d17efd8] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt```
現在,文件就從版本庫中被刪除了。
>另一種情況是刪錯了,因為版本庫里還有呢,所以可以很輕松地把誤刪的文件恢復到最新版本:
$ **git checkout -- test.txt**
git checkout其實是用版本庫里的版本替換工作區的版本,無論工作區是修改還是刪除,都可以“一鍵還原”。
命令**git rm**用于刪除一個文件。如果一個文件已經被提交到版本庫,那么你永遠不用擔心誤刪,但是要小心,你只能恢復文件到最新版本,你會丟失**最近一次提交后你修改的內容。

####7. 遠程倉庫—添加遠程庫—從遠程庫克隆
***
本章開始介紹Git的殺手級功能之一(注意是之一,也就是后面還有之二,之三……):遠程倉庫。

>Git是分布式版本控制系統,同一個Git倉庫,可以分布到不同的機器上。
實際情況往往是這樣,找一臺電腦充當服務器的角色,每天24小時開機,其他每個人都從這個“服務器”倉庫克隆一份到自己的電腦上,并且各自把各自的提交推送到服務器倉庫里,也從服務器倉庫中拉取別人的提交。

完全可以自己搭建一臺運行Git的服務器,不過現階段,為了學Git先搭個服務器絕對是小題大作。好在這個世界上有個叫GitHub的神奇的網站,從名字就可以看出,這個網站就是提供Git倉庫托管服務的,所以,只要注冊一個GitHub賬號,就可以免費獲得Git遠程倉庫。

在繼續閱讀后續內容前,請自行注冊GitHub賬號。
由于你的本地Git倉庫和GitHub倉庫之間的傳輸是通過SSH加密的,所以,需要一點設置:

-  創建**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是公鑰**,可以放心地告訴任何人。

- 登陸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服務器,所以別人也是看不見的。這個方法我們后面會講到的,相當簡單,公司內部開發必備。

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

  首先,登陸GitHub,然后,在右上角找到**“Create a new repo”**按鈕,創建一個新的倉庫:name可以隨便填寫,不一定要與本地相同在Repository name填入learngit,其他保持默認設置,點擊“Create repository”按鈕,就成功地創建了一個新的Git倉庫.

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

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

$ git remote add origin git@github.com:michaelliao/learngit.git```
請千萬注意,把上面的michaelliao替換成你自己的GitHub賬戶名,否則,你在本地關聯的就是我的遠程庫,關聯沒有問題,但是你以后推送是推不上去的,因為你的SSH Key公鑰不在我的賬戶列表中。

添加后,遠程庫的名字就是origin,這是Git默認的叫法,也可以改成別的,但是origin這個名字一看就知道是遠程庫。具體命令請根據網站提示操作;
git remote add origin https://github.com/sunyunzhuo/sungit.git

你也許還注意到,GitHub給出的地址不止一個,還可以用git@github.com:****sunyunzhuo/sungit.git****這樣的地址。實際上,Git支持多種協議,默認的git://使用ssh,但也可以使用https等其他協議。使用https除了速度慢以外,還有個最大的麻煩是每次推送都必須輸入口令,但是在某些只開放http端口的公司內部就無法使用ssh協議而只能用https。

  • 下一步,就可以把本地庫的所有內容推送到遠程庫上:
    $ git push -u origin master把本地庫的內容推送到遠程.

用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文件。現在,遠程庫已經準備好了,下一步是用命令git clone克隆一個本地庫:

$ git clone [git@github.com](mailto:git@github.com):michaelliao/gitskills.git
Cloning into 'gitskills'...
remote: Counting objects: 3, 
done.
remote: Total 3 (delta 0), 
reused 0 (delta 0)
Receiving objects: 100% (3/3), 
done.
$ cd gitskills
$ ls
README.md```
注意把Git庫的地址換成你自己的,然后進入gitskills目錄看看,已經有README.md文件了。
如果有多個人協作開發,那么每個人各自從遠程克隆一份就可以了。小結要克隆一個倉庫,首先必須知道倉庫的地址,然后使用git clone命令克隆。Git支持多種協議,包括https,但通過ssh支持的原生git協議速度最快。

**8、分支管理**
*假設你準備開發一個新功能,但是需要兩周才能完成,第一周你寫了50%的代碼,如果立刻提交,由于代碼還沒寫完,不完整的代碼庫會導致別人不能干活了。如果等代碼全部寫完再一次提交,又存在丟失每天進度的巨大風險。*

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

在[版本回退](http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013744142037508cf42e51debf49668810645e02887691000)里,你已經知道,每次提交,Git都把它們串成一條時間線,這條時間線就是一個分支。截止到目前,只有一條時間線,在Git里,這個分支叫主分支,即master分支。

**HEAD**嚴格來說不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是當前分支。一開始的時候,master分支是一條線,Git用master指向最新的提交,再用HEAD指向master,就能確定當前分支,以及當前分支的提交點:
![git-br-initial](http://upload-images.jianshu.io/upload_images/220694-3ad4c095119cada0?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
**每次提交,master分支都會向前移動一步**,這樣,隨著你不斷交,master分支的線也越來越長.

當我們創建新的分支,例如dev時,Git新建了一個指針叫dev,指向master相同的提交,再把HEAD指向dev,就表示當前分支在dev上:
![git-br-create](http://upload-images.jianshu.io/upload_images/220694-82ea2985f875a8b4?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
你看,Git創建一個分支很快,因為除了增加一個dev指針,改改HEAD的指向,工作區的文件都沒有任何變化!不過,從現在開始,對工作區的修改和提交就是針對dev分支了,比如新提交一次后,dev
指針往前移動一步,而master指針不變:
![git-br-dev-fd](http://upload-images.jianshu.io/upload_images/220694-31f931a4678b6cec?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
假如我們在dev上的工作完成了,就可以把dev合并到master上。Git怎么合并呢?最簡單的方法,就是直接把master指向dev的當前提交,就完成了合并:
![git-br-ff-merge](http://upload-images.jianshu.io/upload_images/220694-f1c22a23caf094b0?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
所以Git合并分支也很快!就改改指針,工作區內容也不變!合并完分支后,甚至可以刪除dev分支。刪除dev分支就是把dev指針給刪掉,刪掉后,我們就剩下了一條master分支:
![git-br-rm](http://upload-images.jianshu.io/upload_images/220694-9dc1c6e87372cd0d?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
真是太神奇了,你看得出來有些提交是通過分支完成的嗎?下面開始實戰。
首先,我們創建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.txt $ git commit -m "branch test"
[dev fec145a] branch test 1 file changed, 1 insertion(+)```
現在,dev分支的工作完成,我們就可以切換回master分支:

$ git checkout master
Switched to branch 'master'```
切換回master分支后,再查看一個readme.txt文件,剛才添加的內容不見了!因為那個提交是在dev分支上,而master分支此刻的提交點并沒有變:


git-br-on-master

現在,我們把dev分支的工作成果合并到master分支上:

$ git merge dev**
Updating d17efd8..fec145a 
Fast-forward readme.txt |    1 + 1 file changed, 1 insertion(+)```

>**git merge命令用于合并指定分支到當前分支**。合并后,再查看readme.txt的內容,就可以看到,和dev分支的最新提交是完全一樣的。
**注意到上面的Fast-forward信息,Git告訴我們,這次合并是“快進模式”,也就是直接把master指向dev的當前提交,所以合并速度非常快。**

當然,也不是每次合并都能Fast-forward,我們后面會將其他方式的合并。合并完成后,就可以放心地**刪除dev分支**了:

$ git branch -d dev
Deleted branch dev (was fec145a).```

刪除后,查看branch,就只剩下master分支了:

$ git branch
 * master```
>因為創建、合并和刪除分支非常快,所以Git鼓勵你使用分支完成某個任務,合并后再刪掉分支,這和直接在master分支上工作效果是一樣的,但過程更安全。

####小結
Git鼓勵大量使用分支:
**查看分支:git branch
創建分支:git branch
切換分支:git checkout
創建+切換分支:git checkout -b
合并某分支到當前分支:git merge
刪除分支:git branch -d**
>**當多個分支修改了同一個文件并提交時,這種情況下,Git無法執行“快速合并”**,只能試圖**把各自的修改合并**起來,但這種**合并就可能會有沖突**,必須手動解決沖突后再提交。git status也可以告訴我們沖突的文件

$ git status

On branch master

Your branch is ahead of 'origin/master' by 2 commits.

Unmerged paths:

(use "git add/rm ..." as appropriate 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.<<<<<<< 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.txt 
$ git commit -m "conflict fixed"
[master 59bc1cb] conflict fixed```

現在,master分支和feature1分支變成了下圖所示:
![git-br-conflict-merged](http://upload-images.jianshu.io/upload_images/220694-afe24f8a366f370a?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
用帶參數的**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).```
工作完成。
##小結
>當Git無法自動合并分支時,就必須首先解決沖突。解決沖突后,再提交,合并完成。

用**git log --graph**命令可以看到**分支合并圖**。
通常,合并分支時,如果可能,Git會用Fast forward模式,**但這種模式下,刪除分支后,會丟掉分支信息**。
>如果要**強制禁用Fast forward模式**,Git就會在merge時**生成一個新的commit,這樣,從分支歷史上就可以看出分支信息**。準備合并dev分支,請注意**--no-ff參數,表示禁用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(+)```

因為本次合并要創建一個新的commit,所以加上-m參數,把commit描述寫進去。合并后,我們用git log看看分支歷史:

$ git log --graph --pretty=oneline --abbrev-commit 
*   7825a50 merge with no-ff 
|\
| * 6224937 add merge 
|/
*   59bc1cb conflict fixed ...```

**分支策略**
>在實際開發中,我們應該按照幾個基本原則進行分支管理:
首先,**master分支應該是非常穩定的**,也就是僅用來發布新版本,**平時不能在上面干活;**那在哪干活呢?干活都在dev分支上,也就是說,dev分支是不穩定的,到某個時候,比如1.0版本發布時,再把dev分支合并到master上,在master分支發布1.0版本

你和你的小伙伴們每個人都在dev分支上干活,每個人都有自己的分支,時不時地往dev分支上合并就可以了。
所以,團隊合作的分支看起來就像這樣:
![git-br-policy](http://upload-images.jianshu.io/upload_images/220694-a54e1c1c80a4585d?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
**小結**
Git分支十分強大,在團隊開發中應該充分應用。
合并分支時,**加上--no-ff參數就可以用普通模式合并,合并后的歷史有分支,能看出來曾經做過合并,而fast forward合并就看不出來曾經做過合并。**

####**bug  分支**
在Git中,由于分支是如此的強大,所以,**每個bug都可以通過一個新的臨時分支來修復,修復后,合并分支,然后將臨時分支刪除。**

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

$ git status

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功能,**可以把當前工作現場“儲藏”起來,等以后恢復現場后繼續工作:
**首先確定要在哪個分支上修復bug,假定需要在master分支上修復,就從master創建臨時分支.
修復完成后,切換到master分支,并完成合并,最后刪除issue-101分支.現在,是時候接著回到dev分支干活了

$ git checkout dev
Switched to branch ‘dev’
$ git status
# On branch devnothing 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 …” 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
#Droppedrefs/stash@{0}(f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)```
再用git stash list查看,就看不到任何stash內容了;
>**你可以多次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’```
5分鐘后,開發完畢:就在此時,接到上級命令,因經費不足,新功能必須取消!雖然白干了,但是這個分支還是必須就地銷毀:

$ 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**。

**小結**
>開發一個新feature,最好新建一個分支;如果要丟棄一個沒有被合并過的分支,可以通過git branch -D 強行刪除。

####**多人協作**
當你**從遠程倉庫克隆時,實際上Git自動把本地的master分支和遠程的master分支對應起來了,并且,遠程倉庫的默認名稱是origin**。

要查看遠程庫的信息,用**git remote**或者,用**git remote -v**顯示可以抓取和推送的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: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命令看看。

現在,你的小伙伴要在dev分支上開發,就必須創建遠程origin的dev分支到本地,于是他用這個命令創建本地dev分支:

$ git checkout -b dev origin/dev
$ git push origin dev```

**向遠程推送dev分支**
>你的小伙伴已經向origin/dev分支推送了他的提交,而碰巧你也對同樣的文件作了修改,并試圖推送.
推送失敗,因為你的小伙伴的最新提交和你試圖推送的提交有沖突.

解決辦法也很簡單,Git已經提示我們,先用git pull把最新的提交從origin/dev抓下來,然后,在本地合并,解決沖突,再推送:
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)
Togit@github.com: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,如果有沖突,要先處理沖突。

9,標簽管理******
發布一個版本時,我們通常先在版本庫中打一個標簽,這樣,就唯一確定了打標簽時刻的版本。將來無論什么時候,取某個標簽的版本,就是把那個打標簽的時刻的歷史版本取出來。所以,
標簽也是版本庫的一個快照。**

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

創建標簽在Git中打標簽非常簡單,首先,切換到需要打標簽的分支上:

$ git branch 
* dev 
  master
$ git checkout master
Switched to branch ‘master’```
然后,敲命令**git tag **就可以打一個新標簽:`$ git  tag  v1.0`
可以用命令**git  tag**查看所有標簽:

$ git tag
v1.0```
默認標簽是打在最新提交的commit上的。有時候,如果忘了打標簽,比如,現在已經是周五了,但應該在周一打的標簽沒有打,怎么辦?

方法是找到歷史提交的commit id,然后打上就可以了:
$ git log –pretty=oneline –abbrev-commit 查看歷史commit

6a5819e merged bug fix 
101cc17032 fix bug 
1017825a50 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 **查看標簽信息:

git show v0.9
commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4
Author: Michael Liao
Date: Thu Aug 22 11:22:08 2013 +0800
add merge
…```
可以看到,v0.9確實打在“add merge”這次提交上。還可以創建帶有說明的標簽,用-a指定標簽名,-m指定說明文字:
$ git tag -a v0.1 -m “version0.1 released” 3628164
用命令git show 可以看到說明文字:

$ git show v0.1 
tag v0.1 
Tagger: Michael Liao 
Date:   Mon Aug 26 07:28:11 2013 +0800
version 0.1 released
commit 3628164fb26d48395383f8f31179f24e0882e1e0 
Author: Michael Liao 
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 availableerror: gpg failed to sign the dataerror: unable to sign the tag`
如果報錯,請參考GnuPG幫助文檔配置Key。
用命令git show 可以看到PGP簽名信息:

$ git show v0.2
tag v0.2
Tagger: Michael Liao
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
Date: Thu Aug 22 10:37:30 2013 +0800
branch test …```
用PGP簽名的標簽是不可偽造的,因為可以驗證PGP簽名**。驗證簽名的方法比較復雜,這里就不介紹了。

小結
命令git tag 用于新建一個標簽,默認為HEAD,
也可以指定一個commit id;git tag -a -m “blablabla…”
可以指定標簽信息;git tag -s -m “blablabla…”
可以用PGP簽名標簽;
命令git tag可以查看所有標簽操作標簽如果標簽打錯了,也可以刪除
$ git tag -d v0.1Deleted tag ‘v0.1′ (was e078af9)**
因為創建的標簽都只存儲在本地,不會自動推送到遠程。
所以,打錯的標簽可以在本地安全刪除。
如果要推送某個標簽到遠程,使用命令git push origin :

$ git push origin  v1.0
Total 0 (delta 0), reused 0 (delta 0)
To [git@github.com](mailto:git@github.com):michaelliao/learngit.git 
* [new tag]         v1.0 -> v1.0```
或者,**一次性推送全部尚未推送到遠程的本地標簽**:

$ git push origin –tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 554 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
*[new tag] v0.2 -> v0.2

  • [new tag] v0.9 -> v0.9```
    如果標簽已經推送到遠程,要刪除遠程標簽就麻煩一點,先從本地刪除
$ git tag -d v0.9
Deleted tag ‘v0.9′ (was 6224937)```
然后,從遠程刪除。刪除命令也是push,但是格式如下:

$ git push origin:refs/tags/v0.9
To git@github.com:michaelliao/learngit.git
– [deleted] v0.9```
要看看是否真的從遠程庫刪除了標簽,可以登陸GitHub查看。

小結
命令git push origin 可以推送一個本地標簽
命令git push origin –tags可以推送全部未推送過的本地標簽;
命令git tag -d 可以刪除一個本地標簽;
命令git push origin :refs/tags/可以刪除一個遠程標簽

在GitHub上,可以任意Fork開源倉庫;自己擁有Fork后的倉庫的讀寫權限;可以推送pull request給官方倉庫來貢獻代碼。

10,自定義GIT

在安裝Git一節中,我們已經配置了user.name和user.email,實際上,Git還有很多可配置項。比如,讓Git顯示顏色,會讓命令輸出看起來更醒目:$ git config –global color.ui true這樣,Git會適當地顯示不同的顏色

忽略特殊文件
有些時候,你必須把某些文件放到Git工作目錄中但又不能提交它們,比如保存了數據庫密碼的配置文件啦等等,每次git status都會顯示Untracked files …,有強迫癥的童鞋心里肯定不爽。好在Git考慮到了大家的感受,這個問題解決起來也很簡單,在Git工作區根目錄下創建一個特殊的.gitignore文件,然后把要忽略的文件名填進去,Git就會自動忽略這些文件。不需要從頭寫.gitignore文件,GitHub已經為我們準備了各種配置文件,只需要組合一下就可以使用了。

所有配置文件可以直接在線瀏覽:https://github.com/github/gitignore

忽略文件的原則是:忽略操作系統自動生成的文件,比如縮略圖等;
忽略編譯生成的中間文件、可執行文件等,也就是如果一個文件是通過另一個文件自動生成的,那自動生成的文件就沒必要放進版本庫,比如Java編譯產生的.class文件;
忽略你自己的帶有敏感信息的配置文件,比如存放口令的配置文件。

舉個例子:
假設你在Windows下進行Python開發,Windows會自動在有圖片的目錄下生成隱藏的縮略圖文件.
如果有自定義目錄,目錄下就會有Desktop.ini文件.因此你需要忽略Windows自動生成的垃圾文件:Windows:Thumbs.db ehthumbs.db Desktop.ini
然后,繼續忽略Python編譯產生的.pyc、.pyo、dist等文件或目錄:Python: *.py[cod] *.so *.egg *.egg -info dist build加上你自己定義的文件,最終得到一個完整的.gitignore文件.
內容如下

# Windows:Thumbs.db ehthumbs.db  Desktop.ini
# Python:*.py[cod] *.so *.egg *.egg-info dist build
# My configurations:db.ini deploy_key_rsa```
最后一步就是把**.gitignore****也提交到Git**,就完成了!

當然檢驗.gitignore的標準是git status命令是不是說working directory clean。
使用Windows的童鞋注意了,如果你在資源管理器里新建一個.gitignore文件,它會非常弱智地提示你必須輸入文件名,但是在文本編輯器里“保存”或者“另存為”就可以把文件保存為.gitignore了。小結忽略某些文件時,需要編寫.gitignore;.gitignore文件本身要放到版本庫里,并且可以對.gitignore做版本管理!

**配置別名**
我們只需要敲一行命令,告訴Git,以后st就表示status:

$ git config –global alias.st status
$ 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 adca45d317e6d8a4b23f9811c3d7b7f0f180bfe2
Merge: bd6ae48 291bea8
Author: Michael Liao
Date:   Thu Aug 22 22:49:22 2013 +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的時候,加上–global是針對當前用戶起作用的,電腦下所有庫都起作用;如果不加,那只針對當前的倉庫起作用。

**配置文件放哪了?**
每個倉庫的Git配置文件都放在**.git/config**文件中:

$ cat .git/config
[core] repository
formatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true[remote "origin"]
url = git@github.com:michaelliao/learngit.git
fetch = +refs/heads/:refs/remotes/origin/[branch "master"]
remote = origin
merge = refs/heads/master
[alias] last = log -1```
別名就在[alias]后面,要刪除別名,直接把對應的行刪掉即可。

而當前用戶的Git配置文件放在用戶主目錄下的一個隱藏文件.gitconfig中:Git的官方網站:http://git-scm.com,英文自我感覺不錯的童鞋,可以經常去官網看看

搭建Git服務器

在遠程倉庫一節中,我們講了遠程倉庫實際上和本地倉庫沒啥不同,純粹為了7×24小時開機并交換大家的修改。GitHub就是一個免費托管開源代碼的遠程倉庫。但是對于某些視源代碼如生命的商業公司來說,既不想公開源代碼,又舍不得給GitHub交保護費,那就只能自己搭建一臺Git服務器作為私有倉庫使用。

搭建Git服務器需要準備一臺運行Linux的機器,強烈推薦用Ubuntu或Debian,這樣,通過幾條簡單的apt命令就可以完成安裝。
第一步,安裝git:$ sudo apt-get install git**
第二步,創建一個git用戶,用來運行git服務:$ sudo adduser git
第三步,創建證書登錄:**收集所有需要登錄的用戶的公鑰,就是他們自己的id_rsa.pub文件,把所有公鑰導入到/home/git/.ssh/authorized_keys文件里,一行一個。
第四步,初始化Git倉庫:先選定一個目錄作為Git倉庫,假定是/srv/sample.git,在/srv目錄下輸入命令:$ sudo git init –bare sample.gitGit就會創建一個裸倉庫,裸倉庫沒有工作區,因為服務器上的Git倉庫純粹是為了共享,所以不讓用戶直接登錄到服務器上去改工作區,并且服務器上的Git倉庫通常都以.git結尾。然后,把owner改為git:$ sudo chown -R git:git sample.git
第五步,禁用shell登錄:出于安全考慮,第二步創建的git用戶不允許登錄shell,這可以通過編輯/etc/passwd文件完成。找到類似下面的一行:git:x:1001:1001:,,,:/home/git:/bin/bash改為:git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell這樣,git用戶可以正常通過ssh使用git,但無法登錄shell,因為我們為git用戶指定的git-shell每次一登錄就自動退出。
第六步,克隆遠程倉庫:現在,可以通過git clone命令克隆遠程倉庫了,在各自的電腦上運行:$ git clone git@server:/srv/sample.gitCloning into ‘sample’…warning: You appear to have cloned an empty repository.剩下的推送就簡單了。

管理公鑰
如果團隊很小,把每個人的公鑰收集起來放到服務器的/home/git/.ssh/authorized_keys文件里就是可行的。如果團隊有幾百號人,就沒法這么玩了,這時,可以用Gitosis來管理公鑰。這里我們不介紹怎么玩Gitosis了,幾百號人的團隊基本都在500強了,相信找個高水平的Linux管理員問題不大。

管理權限
有很多不但視源代碼如生命,而且視員工為竊賊的公司,會在版本控制系統里設置一套完善的權限控制,每個人是否有讀寫權限會精確到每個分支甚至每個目錄下。

因為Git是為Linux源代碼托管而開發的,所以Git也繼承了開源社區的精神,不支持權限控制。不過,因為Git支持鉤子(hook),所以,可以在服務器端編寫一系列腳本控制提交等操作,達到權限控制的目的Gitolite就是這個工具。這里我們也不介紹Gitolite了,不要把有限的生命浪費到權限斗爭中。

小結
搭建Git服務器非常簡單,通常10分鐘即可完成;要方便管理公鑰,用Gitosis;要像SVN那樣變態地控制權限,用Gitolite。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,401評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,011評論 3 413
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,263評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,543評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,323評論 6 404
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,874評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,968評論 3 439
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,095評論 0 286
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,605評論 1 331
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,551評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,720評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,242評論 5 355
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 43,961評論 3 345
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,358評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,612評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,330評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,690評論 2 370

推薦閱讀更多精彩內容

  • Git是目前最流行的版本管理系統,也是最先進的分布式版本控制系統(distributed version cont...
    pro648閱讀 5,736評論 1 17
  • 今天依舊是古詩磨耳朵喚醒。對古詩歌曲特別感興趣,然后送她上學的路上還是一直拿著古時手機在聽,我圖圖喜歡反復的聽一首...
    貴在堅持圖媽有力氣閱讀 262評論 0 0
  • RunLoop,從字面意思看叫做運行循環。RunLoop基本作用: 保持程序的持續運行 處理APP中的各種事件(觸...
    YY_Lee閱讀 364評論 2 9
  • 清晨,我拖著疲倦的眸子,倚在窗前,看第一縷曙光灑在對面的高樓上,我們一起醒來,一起開始新的一天。此時因為陽光我看見...
    望穿天花板閱讀 474評論 0 0
  • 新年中的樂與悶,大概自己知道.
    孩子們的痞子媽閱讀 228評論 0 0