Git分佈式版本工具的部署與使用

1、Git概述

1. Git誕生

不少人都知道,Linus在1991年建立了開源的Linux,今後,Linux系統不斷髮展,已經成爲最大的服務器系統軟件了。
Linus雖然建立了Linux,但Linux的壯大是靠全世界熱心的志願者參與的,這麼多人在世界各地爲Linux編寫代碼,那Linux的代碼是如何管理的呢?git

事實是,在2002年之前,世界各地的志願者把源代碼文件經過diff的方式發給Linus,而後由Linus本人經過手工方式合併代碼。
不過,到了2002年,Linux系統已經發展了十年了,代碼庫之大讓Linus很難繼續經過手工方式管理了,社區的弟兄們也對這種方式表達了強烈不滿,因而Linus選擇了一個商業的版本控制系統BitKeeper(源代碼控制管理系統),BitKeeper的東家BitMover公司出於人道主義精神,受權Linux社區無償使用這個版本控制系統。
到了2005年,Linux社區牛人彙集,有一夥人開發Samba的Andrew試圖破解BitKeeper的協議,結果被BitMover公司發現了,因而BitMover公司怒了,要收回Linux社區的無償使用權。
這個時候,Linus向BitMover公司道個歉,保證之後之後不會在發生這樣的事情。github

以後,Linus花了兩週時間本身用C寫了一個分佈式版本控制系統,這就是Git!一個月以內,Linux系統的源碼已經由Git管理了。
Git迅速成爲最流行的分佈式版本控制系統,尤爲是2008年,GitHub網站上線了,它爲開源項目免費提供Git存儲,無數開源項目開始遷移至GitHub,包括jQuery,PHP,Ruby等等。安全

歷史就是這麼偶然,若是不是當年BitMover公司威脅Linux社區,可能如今咱們就沒有免費而超級好用的Git了。到目前爲止,Git能夠在Linux、Unix、Mac和Windows這幾大平臺上正常運行了。bash

2. Git簡介

(1)Git是什麼?
Git是目前世界上最早進的分佈式版本控制系統。
Git是一個開源的分佈式版本控制軟件,能夠有效、高速的處理從很小到很是大的項目版本管理。服務器

(2)那什麼是版本控制系統?
若是你用Microsoft Word寫過長篇大論,那你必定有這樣的經歷:app

想刪除一個段落,又怕未來想恢復找不回來怎麼辦?有辦法,先把當前文件「另存爲……」一個新的Word文件,再接着改,改到必定程度,再「另存爲……」一個新文件,這樣一直改下去,最後你的Word文檔變成了這樣:
Git分佈式版本工具的部署與使用dom

過了一段時間,你想找回被刪除的文字,可是已經記不清刪除前保存在哪一個文件裏了,只好一個一個文件去找,就會以爲很麻煩。
看着這樣一大堆亂七八糟的文件,想保留最新的一個,而後把其餘的刪掉,又怕哪天會用上,還不敢刪。ssh

因而你就會想,若是有一個軟件,不但能自動幫我記錄每次文件的改動(相似於騰訊的TIM在線文檔編輯),這樣就不用本身管理一堆相似的文件了。若是想查看某次改動,只須要在軟件裏瞄一眼就能夠,這樣是否是很方便?分佈式

這樣,就結束了手動管理多個「版本」的史前時代,進入到版本控制時代。ide

2、Git分佈式

1. 集中式版本控制系統

集中式版本控制系統,版本庫是集中存放在中央服務器的,而幹活的時候,用的都是本身的電腦,因此要先從中央服務器取得最新的版本,而後開始幹活,幹完活了,再把本身的活推送給中央服務器。中央服務器就比如是一個圖書館,你要看一本書,必須先從圖書館借出來,而後回家本身看,看完了,再放回圖書館。
Git分佈式版本工具的部署與使用

集中式版本控制系統最大的缺點就是必須聯網才能工做,若是在局域網內還好。

2. 分佈式版本控制系統

分佈式版本控制系統根本沒有「中央服務器」,每一個人的電腦上都是一個完整的版本庫,這樣,你工做的時候,就不須要聯網了,由於版本庫就在你本身的電腦上。既然每一個人電腦上都有一個完整的版本庫,那多我的如何協做呢?比方說你在本身電腦上改了文件A,你的同事也在他的電腦上改了文件A,這時,大家倆之間只需把各自的修改推送給對方,就能夠互相看到對方的修改了。

和集中式版本控制系統相比,分佈式版本控制系統的安全性要高不少,由於每一個人電腦裏都有完整的版本庫,某一我的的電腦壞掉了沒關係,隨便從其餘人那裏複製一個就能夠了。而集中式版本控制系統的中央服務器要是出了問題,全部人都無法幹活了。
Git分佈式版本工具的部署與使用

3. Git與SVN的主要區別

這兩個工具主要的區別在於歷史版本維護的位置。
Git本地倉庫包含代碼庫還有歷史庫,在本地的環境開發就能夠記錄歷史。
而SVN的歷史庫存在於中央倉庫,每次對比與提交代碼都必須鏈接到中央倉庫才能進行。

4. 使用Git的好處在於

本身能夠在脫機環境查看開發的版本歷史;多人開發時若是充當中央倉庫的Git倉庫掛了,任何一個開發者均可以隨時建立一個新的中央庫,而後同步就馬上恢復了中央庫。

3、Git原理

Git分佈式版本工具的使用流程以下:
工做區(Working Directory)-->版本庫(Repository)暫緩區-->倉庫

1. 工做區(Working Directory)

就是咱們在本機裏能看到的目錄,好比個人gittest文件夾就是一個工做區。

[root@git gittest]# pwd
/root/gittest

2. 版本庫(Repository)

工做區有一個隱藏目錄.git,這個不算工做區,而是Git的版本庫。
Git的版本庫裏存了不少東西,其中最重要的就是稱爲stage(或者叫index)的暫存區,還有Git爲咱們自動建立的第一個分支master,以及指向master的一個指針叫HEAD。
Git分佈式版本工具的部署與使用

咱們把文件往Git版本庫裏添加的時候,要執行兩步:
第一步:git add 把文件添加進去,實際上就是把文件添加到暫存區;
第二步:git commit -m "版本描述信息" 提交到版本庫,實際上就是把暫存區的全部內容提交到倉庫的當前分支。

建立Git版本庫時,Git自動爲咱們建立了一個master分支,因此git commit就是往master分支上提交更改。
你能夠簡單理解爲,須要提交的文件修改統統放到暫存區,而後,一次性提交暫存區的全部修改。
當工做區有文件更改,執行git add時,暫緩區就變成以下這樣:
Git分佈式版本工具的部署與使用

git add 命令實際上就是把工做區要提交的內容放到暫存區(Stage),而後,執行git commit就能夠一次性把暫存區的全部修改提交到分支
一但執行git commit提交後,那麼工做區就是「乾淨」的:
如今版本庫變成了這樣,暫存區就沒有任何內容了:
Git分佈式版本工具的部署與使用

以上就是git分佈式版本工具的流程,沒看明白的童鞋,能夠再多看一次。

4、安裝Git

這裏我使用Centos 7系統來安裝Git。
兩種安裝方法(選其一就行了):

  • 使用yum安裝;
  • 使用源碼包安裝。

方法一:

[root@git ~]# yum -y install git-core
[root@git ~]# git --version      --查看版本號
git version 2.16.0

方法二:
1. 獲取Git源碼包
能夠去下面的網址去下載Git的源碼包:

[root@git ~]# wget https://www.kernel.org/pub/software/scm/git/git-2.16.0.tar.gz
或
[root@git ~]# wget https://github.com/git/git/archive/v2.16.0.tar.gz

我這裏下載了2.16.0版本的源碼包
git-2.16.0.tar.gz

2. 在CentOS 7上安裝Git
從Git官網下載源碼,而後解壓,依次輸入:./configure,make,sudo make install這幾個命令安裝就行了。

# tar xvf git-2.16.0.tar.gz -C /usr/src/         --解壓
# cd /usr/src/git-2.16.0/                             --進入解壓以後的路徑
# ./configure                                              --配置
# make && make install                            --編譯和安裝
# git --version                                            --查看版本號
git version 2.16.0

5、建立本地工做區

由於Git是分佈式版本控制系統,因此,上傳版本文件時必須提供:你的名字和Email地址。

[root@git ~]# git config --global user.name "xiaozuoxiansen"
[root@git ~]# git config --global user.email "2947853874@qq.com"

版本庫又名倉庫,英文名repository,能夠理解成一個目錄,這個目錄裏面的全部文件都被Git管理起來,每一個文件的修改、刪除,Git都能跟蹤.

第一步:建立一個版本庫,建立一個目錄:

[root@git ~]# mkdir gittest
[root@git ~]# cd gittest/
[root@git gittest]# pwd
/root/gittest

第二步:git init命令把該目錄初始化爲Git能夠管理的倉庫

[root@git gittest]# git init
已初始化空的 Git 倉庫於 /root/gittest/.git/

使用tree命令能夠查看/root/gittest/.git/目錄下的樹結構

[root@git gittest]# tree /root/gittest/.git/
/root/gittest/.git/
|-- branches
|-- config
|-- description
|-- HEAD
|-- hooks
|   |-- applypatch-msg.sample
|   |-- commit-msg.sample
|   |-- fsmonitor-watchman.sample
|   |-- post-update.sample
|   |-- pre-applypatch.sample
|   |-- pre-commit.sample
|   |-- prepare-commit-msg.sample
|   |-- pre-push.sample
|   |-- pre-rebase.sample
|   |-- pre-receive.sample
|   `-- update.sample
|-- info
|   `-- exclude
|-- objects
|   |-- info
|   `-- pack
`-- refs
    |-- heads
    `-- tags

9 directories, 15 files

開始編寫一個README自述文件

[root@git gittest]# echo "##README file" > README

使用git status 查看當前工做區的狀態

[root@git gittest]# git status
位於分支 master
尚無提交
未跟蹤的文件:
  (使用 "git add <文件>..." 以包含要提交的內容)
    README                           --有一個新的文件README,提示可使用git add <file>提交至暫存區
提交爲空,可是存在還沒有跟蹤的文件(使用 "git add" 創建跟蹤)

使用git add 命令 將剛在工做區建立的README提交至暫存區

[root@git gittest]# git  add README       --將README提交到暫存區
[root@git gittest]# git  status                    --查看當前工做區的狀態
位於分支 master
尚無提交
要提交的變動:
  (使用 "git rm --cached <文件>..." 以取消暫存)
    新文件:   README           --新的文件README,提示可使用git rm --cached <文件>取消暫存

使用git commit -m "描述信息"將暫存區的文件提交至本地倉庫,

[root@git gittest]# git commit -m "first README"      -- -m表示添加說明,first README爲說明內容,此內容自定義
[master(根提交) 6c2a0d6] first README
 1 file changed, 1 insertion(+)
 create mode 100644 README

[root@git gittest]# git status         --查看當前工做區的狀態,提交以後,暫存區無內容能夠提交
位於分支 master
無文件要提交,乾淨的工做區

6、文件對比

有時候咱們修改了本地的一個文件,但臨時有事走開了,回來的時候忘記了本身作了哪部分的修改。
此時就要用上git diff命令,進行文件對比。

[root@git gittest]# echo "##new add test" >> README        --向README文件添加內容
[root@git gittest]# git status                                                   --查看當前工做區的狀態
位於分支 master
還沒有暫存以備提交的變動:
  (使用 "git add <文件>..." 更新要提交的內容)
  (使用 "git checkout -- <文件>..." 丟棄工做區的改動)
    修改:     README                                --顯示README文件已經被修改過了
修改還沒有加入提交(使用 "git add" 和/或 "git commit -a")

[root@git gittest]# git diff README         --使用git diff 命令對比README文件查看和上次提交到倉庫的內容與如今的文件哪些地方被修改過了
diff --git a/README b/README
index 9383c5a..29dcf26 100644
--- a/README
+++ b/README
@@ -1 +1,2 @@
 ##README file
+##new add test                                        --最前面的+號表示README文件新增長的內容

知道本身修改了什麼,那麼接下來就能夠放心的提交了

[root@git gittest]# git add README                               --提交至暫存區
[root@git gittest]# git commit -m "second README"     --提交到本地倉庫
[master c973a69] second README
 1 file changed, 1 insertion(+)                                          --表示README文件1行被修改,新增1行

[root@git gittest]# git status                                            --再次查看狀態時,顯示無內容可提交
位於分支 master
無文件要提交,乾淨的工做區

7、版本回退

什麼是版本庫呢?版本庫又名倉庫,英文名repository,你能夠簡單理解成一個目錄,這個目錄裏面的全部文件均可以被Git管理起來,每一個文件的修改、刪除,Git都能跟蹤,以便任什麼時候刻均可以追蹤歷史,或者在未來某個時刻能夠「還原」。
在實際工做中,咱們提交的版本能夠有不少,很難記得每次提交了什麼內容,或是何時提交的,這裏就要用上git log命令來查看提交的版本。

[root@git gittest]# git log                     --查看提交日誌
commit c973a69ebb25b5def81d4b6ce57f487a97f37369 (HEAD -> master)
Author: xiaozuoxiansen <2947853874@qq.com>
Date:   Mon Feb 5 14:35:14 2018 +0800

    second README                            --這是我第二次提交

commit 6c2a0d6fb6fa30103d60e4d993357c3dbffa5c8b
Author: xiaozuoxiansen <2947853874@qq.com>
Date:   Mon Feb 5 14:23:42 2018 +0800

    first README                                   --這是我第一次提交

能夠看出,最近提交的一次顯示在最上面。
也能夠看到有兩個版本,時間點也能夠看獲得,提交人和郵件也能夠看獲得,第一行的commit 後面的那一連串的字符是commit id是惟一標識符。

在生產環境中咱們提交的版本有太多太多,要是這麼看的話,不方便看,此時咱們能夠加上--pretty=oneline參數:這樣顯示就簡潔多了。

[root@git gittest]# git log --pretty=oneline
c973a69ebb25b5def81d4b6ce57f487a97f37369 second README
6c2a0d6fb6fa30103d60e4d993357c3dbffa5c8b first README

在Git中,咱們首先要知道當前是哪一個版本,之前有哪些版本,用HEAD表示當前版本,上一個版本就是HEAD^,上上一個版本就是HEAD^^,固然往上100個版本寫100個^比較容易數不過來,因此寫成HEAD~100。也能夠指定版本的commit id的前4位以上也能夠。

[root@git gittest]# git log --pretty=oneline          --列出版本號
c973a69ebb25b5def81d4b6ce57f487a97f37369 second README
6c2a0d6fb6fa30103d60e4d993357c3dbffa5c8b first README

[root@git gittest]# git reset --hard 6c2a             --回退到commit id開頭爲6c2a的版本
HEAD 如今位於 6c2a0d6 first README

[root@git gittest]# git log --pretty=oneline          --查看當前的版本
6c2a0d6fb6fa30103d60e4d993357c3dbffa5c8b first README

[root@git gittest]# cat README                        --查看內容,回退成功
##README file

如今你回退到了某個版本,關掉了電腦,次日早上就後悔了,想恢復到新版本怎麼辦?找不到新版本的commit id怎麼辦?
在Git中,老是有後悔藥能夠吃的。當你用 git reset --hard HEAD^回退到second README版本時,再想恢復到first README,就必須找到first README的commit id。
Git提供了一個命令git reflog用來記錄你的每一次命令。

[root@git gittest]# git reflog                               --列出了全部的commit的操做和reset回退的操做,還顯示了對應的commit id
6c2a0d6 (HEAD -> master) HEAD@{0}: reset: moving to 6c2a
c973a69 HEAD@{1}: commit: second README
6c2a0d6 (HEAD -> master) HEAD@{2}: commit (initial): first README

[root@git gittest]# git reset --hard c973a69      --輸入最後一次提交的commit id 回退
HEAD 如今位於 c973a69 second README

[root@git gittest]# git log --pretty=oneline        --查看當前的版本
c973a69ebb25b5def81d4b6ce57f487a97f37369 (HEAD -> master) second README
6c2a0d6fb6fa30103d60e4d993357c3dbffa5c8b first README

[root@git gittest]# cat README                      --驗證下內容,是新後一次提交的內容
##README file
##new add test

總結:

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

8、修改、撤銷、刪除

1. 管理修改

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

爲何說Git管理的是修改,而不是文件呢?咱們仍是作一個測試。
第一步:對README文件作一個修改,好比加一行內容

[root@git gittest]# echo "hello world" >> README        --向README文件添加內容
[root@git gittest]# cat README 
##README file
##new add test
hello world

第二步:添加

[root@git gittest]# git add README
[root@git gittest]# git status 
位於分支 master
要提交的變動:
  (使用 "git reset HEAD <文件>..." 以取消暫存)

    修改:     README

第三步:再次修改README文件,好比再加一行內容

[root@git gittest]# echo "test" >> README                    --向README文件添加內容
[root@git gittest]# cat README 
##README file
##new add test
hello world
test

第四步:提交

[root@git gittest]# git diff README                          --是工做區(work dict)和暫存區(stage)的比較
diff --git a/README b/README
index 1d755e7..0745038 100644
--- a/README
+++ b/README
@@ -1,3 +1,4 @@
 ##README file
 ##new add test
 hello world
+test

[root@git gittest]# git diff --cached README    --是暫存區(stage)和分支(master)的比較
diff --git a/README b/README
index 29dcf26..1d755e7 100644
--- a/README
+++ b/README
@@ -1,2 +1,3 @@
 ##README file
 ##new add test
+hello world

[root@git gittest]# git diff HEAD -- README     --查看工做區和版本庫裏面最新版本的區別
diff --git a/README b/README
index 29dcf26..0745038 100644
--- a/README
+++ b/README
@@ -1,2 +1,4 @@
 ##README file
 ##new add test
+hello world
+test

[root@git gittest]# git commit README -m "third README"     --加了文件名,所有被提交
[master bcb96a1] third README
 1 file changed, 2 insertions(+)

[root@git gittest]# git commit -m "third README"                     --不加文件名,只有暫存區被提交

2. 撤銷修改

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

[root@git gittest]# echo "場景一 test" >> README                  --向README文件添加內容
[root@git gittest]# cat README 
##README file
##new add test
hello world
test
場景一 test

[root@git gittest]# git status                                                   --查看狀態,顯示README文件被修改
位於分支 master
還沒有暫存以備提交的變動:
  (使用 "git add <文件>..." 更新要提交的內容)
  (使用 "git checkout -- <文件>..." 丟棄工做區的改動)
    修改:     README
修改還沒有加入提交(使用 "git add" 和/或 "git commit -a")

[root@git gittest]# git checkout --  README    --此時若是要撤消修改,則執行該命令

[root@git gittest]# git status                              --再次看狀態,顯示沒有文件修改或添加
位於分支 master
無文件要提交,乾淨的工做區

[root@git gittest]# cat README                       --再次查看README內容時,內容已經撤消成功
##README file
##new add test
hello world
test

git checkout -- file 命令中的--很重要,沒有--,就變成了「切換到另外一個分支」的命令

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

[root@git gittest]# echo "場景二 test" >> README        --向README文件添加內容
[root@git gittest]# cat README 
##README file
##new add test
hello world
test
場景二 test

[root@git gittest]# git status                 --查看狀態,顯示README文件被修改
位於分支 master
還沒有暫存以備提交的變動:
  (使用 "git add <文件>..." 更新要提交的內容)
  (使用 "git checkout -- <文件>..." 丟棄工做區的改動)
    修改:     README
修改還沒有加入提交(使用 "git add" 和/或 "git commit -a")

[root@git gittest]# git add README
[root@git gittest]# git status           --當咱們修改一個文件執行了git add後,再看狀態時,會提示執行git reset HEAD <file> 能夠撤消到工做區
位於分支 master
要提交的變動:
  (使用 "git reset HEAD <文件>..." 以取消暫存)
    修改:     README

[root@git gittest]# git reset HEAD README       --把README暫存區修改的內容撤消到工做區
重置後取消暫存的變動:
M   README

[root@git gittest]# git status                                 --再次查看狀態時,顯示文件已經到了工做區
位於分支 master
還沒有暫存以備提交的變動:
  (使用 "git add <文件>..." 更新要提交的內容)
  (使用 "git checkout -- <文件>..." 丟棄工做區的改動)
    修改:     README
修改還沒有加入提交(使用 "git add" 和/或 "git commit -a")

[root@git gittest]# git checkout -- README        --再執行git checkout -- README把修改的內容從工做區裏撤消

[root@git gittest]# cat README                          --再次查看README內容時,內容已經撤消成功
##README file
##new add test
hello world
test

3. 刪除文件

場景一:誤刪了工做區的某個文件;
若是誤刪了工做區的某個文件,能夠從倉庫裏恢復,測試以下:

[root@git gittest]# rm README                     --刪除文件
rm:是否刪除普通文件 "README"?y
[root@git gittest]# ls                                       --文件已經被刪除
[root@git gittest]#

[root@git gittest]# git status                           --查看狀態,顯示工做區文件README文件被標記爲刪除
位於分支 master
還沒有暫存以備提交的變動:
  (使用 "git add/rm <文件>..." 更新要提交的內容)
  (使用 "git checkout -- <文件>..." 丟棄工做區的改動)
    刪除:     README
修改還沒有加入提交(使用 "git add" 和/或 "git commit -a")

[root@git gittest]# git checkout -- README    --此時執行git checkout -- <file> 能夠將刪除的文件撤消

[root@git gittest]# git status 
位於分支 master
無文件要提交,乾淨的工做區

[root@git gittest]# ls               --再查看時文件已經恢復回來
README

場景二:確認要刪除倉庫的某個文件,git rm命令
測試以下:

[root@git gittest]# git rm README    --刪除工做區的文件README
rm 'README'

[root@git gittest]# git status               --查看狀態,README已經被標識爲delete
位於分支 master
要提交的變動:
  (使用 "git reset HEAD <文件>..." 以取消暫存)
    刪除:     README

[root@git gittest]# git commit -m "delete README"       -執行提交到倉庫
[master 09be905] delete README
 1 file changed, 4 deletions(-)
 delete mode 100644 README

[root@git gittest]# ls                  --文件已經被完全刪除
[root@git gittest]#

9、遠程倉庫GitHub

Git分佈式版本控制系統,同一個Git倉庫,能夠分佈到不一樣的機器上。最開始只有一臺機器有一個原始版本庫,此後,別的機器能夠「克隆」這個原始版本庫,並且每臺機器的版本庫其實都是同樣的,並無主次之分。
實際工做環境中,是找一臺電腦充當服務器的角色,7 * 24小時開機,我的電腦都從這個「服務器」倉庫克隆一份到本身的電腦上,而且各自把各自的提交推送到服務器倉庫裏,也從服務器倉庫中拉取別人的提交。

固然這裏不講本地環境中的倉庫,咱們講官方GitHub代碼託管網站,這是一個免費代碼託管服務,因此,只要註冊一個GitHub帳號,就能夠免費得到Git遠程倉庫。
GitHub官方網站:https://github.com 你們自行註冊。

GitHub註冊成功後,咱們還須要進行一些設置,建立ssh-key才能夠將我的電腦中的內容提交到GitHub中來,GitHub爲何要ssh-key呢?由於GitHub須要識別出你推送提交確實是你推送的,而不是別人冒充的,而Git支持SSH協議,因此,GitHub只要知道了你的公鑰,就能夠確認只有你本身才能推送。

GitHub容許你添加多個Key。假定你有若干電腦,你一下子在公司提交,一下子在家裏提交,只要把每臺電腦的Key都添加到GitHub,就能夠在每臺電腦上往GitHub推送了。

舒適提示:在GitHub上免費託管的Git倉庫,任何人均可以看到,且還能夠評論,但只有你本身才能夠修改,因此,敏感信息就要慎重了。

第一步:建立ssh-key

[root@git ~]# ssh-keygen -t rsa -C 」2947853874@qq.com「           --把郵箱換成你本身的郵箱,而後一直回車到結束
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
76:82:32:ca:9e:34:b1:d3:28:b9:02:97:49:3b:73:e6 」2947853874@qq.com「
The key''s randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|  .    .         |
| ..+o . S .      |
|.oB*oo . o       |
|+.O*.            |
|.= +E            |
|o o              |
+-----------------+

[root@git ~]# ll ~/.ssh/                      --查看家目錄下的.ssh目錄下有兩個文件id_rsa私鑰,不可泄露, id_rsa.pub公鑰,對外提供的,能夠放心提供給任何人。
總用量 8
-rw------- 1 root root 1679 2月   5 15:56 id_rsa
-rw-r--r-- 1 root root  405 2月   5 15:56 id_rsa.pub

[root@git ~]# cat ~/.ssh/id_rsa.pub    --查看公鑰內容,複製,後面有用
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYyuSvWHN/0xR4aEiCLcPlkPcdBt82J8MDAVDSVt+5PSAZUIe61JpB5PP5QvSN5+C9qmBgxgeNuriOd+odCyhV8SUxt8SVLpcntG8yjjaE/zFVdB2Nb3B+w13f4FIxBo+6MjboyJUi6xnjrrbPtk8L4hfmIO/3TQ1SXceycIDanXNsuzgWT0sYxIcTMfHyhNY5ogIILutyTkHziGWoJH2TY73D1GUE+u0a/NbezBIeJeEJ/jowsoVVTY4ZcKjxL1r0ivc/AB7+bUriMSDZpmsk4A473EidFoa5fNv+14Gk1Nsve5WpmntFHWRhqye3QtZkMsOEcnVYw6UMomzsvh/h 」2947853874@qq.com「

第二步:登錄GitHub網站
點擊頭像 >> 點擊settings >> 點向SSH and GPG keys >> New SSH key >> Title自定義 >> Key 就是上面的id_rsa.pub的內容複製上來 >> Add SSH key
Git分佈式版本工具的部署與使用
點擊「Add SSH key」以後,以下圖所示:
Git分佈式版本工具的部署與使用

第三步:建立遠程倉庫
點擊頭像旁邊的 + 號 >> New repository >> Repository name 處填寫倉庫名稱(本身命名,我這寫的是test) >> 點擊Create repository 建立倉庫
Git分佈式版本工具的部署與使用
點擊「Create repository 」以後,以下圖所示:
Git分佈式版本工具的部署與使用
GitHub上剛建立的倉庫test倉庫是空的,GitHub在界面上提示,能夠從這個倉庫克隆出新的倉庫,也能夠把一個已有的本地倉庫與之關聯,而後,把本地倉庫的內容推送到GitHub倉庫。

根據GitHub的提示,在本地的learngit倉庫下運行如下兩條命令:
第一條:git remote add origin https://github.com/xiaozuoxiansen/test.git
注意:把上面的xiaozuoxiansen替換成你本身的GitHub帳戶名,test替換爲你本身在GitHub上建立的倉庫名,不然,你在本地關聯的就是個人遠程庫,關聯沒有問題,可是你之後推送是推不上去的,由於你的SSH Key公鑰不在個人帳戶列表中。

[root@git gittest]# git remote add origin https://github.com/xiaozuoxiansen/test.git
[root@git gittest]#

第二條:git push -u origin master
把本地庫的內容推送到遠程GitHub倉庫,用git push命令,其實是把當前分支master推送到遠程。

因爲遠程庫是空的,咱們第一次推送master分支時,加上了-u參數,Git不但會把本地的master分支內容推送的遠程新的master分支,還會把本地的master分支和遠程的master分支關聯起來,在之後的推送或者拉取時就能夠簡化命令:git push

[root@git gittest]# git push -u origin master
Username for 'https://github.com': xiaozuoxiansen           --要求你輸入GitHub官方的賬號
Password for 'https://xiaozuoxiansen@github.com':         --要求你輸入GitHub官方賬號對應的密碼
對象計數中: 11, 完成.
壓縮對象中: 100% (4/4), 完成.
寫入對象中: 100% (11/11), 902 bytes | 451.00 KiB/s, 完成.
Total 11 (delta 0), reused 0 (delta 0)
To https://github.com/xiaozuoxiansen/test
 * [new branch]      master -> master
分支 'master' 設置爲跟蹤來自 'origin' 的遠程分支 'master'。

推送成功後,能夠在GitHub頁面中看到遠程庫的內容已經和本地是同樣的
Git分佈式版本工具的部署與使用

前面說到的是在GitHub建立倉庫,且把本地的倉庫關聯到GitHub中的公共倉庫。
接下來說從遠程倉庫中克隆到本地倉庫中來
如今,假設咱們從零開始,那麼最好的方式是先建立遠程庫,而後從遠程庫克隆。
登錄GitHub,建立一個新的倉庫,名字叫project,
勾選Initialize this repository with a README,
這樣GitHub會自動爲咱們建立一個README.md文件。
Git分佈式版本工具的部署與使用
建立完畢後,能夠看到README.md文件:
Git分佈式版本工具的部署與使用
接下來用命令git clone將GitHub的遠程倉庫克隆到本地來。

[root@git gittest]# git clone https://github.com/xiaozuoxiansen/project.git
正克隆到 'project'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
展開對象中: 100% (3/3), 完成.
[root@git gittest]# 
[root@git gittest]# 
[root@git gittest]# ls
project
[root@git gittest]# ls project/
README.md

注意把Git庫的用戶名xiaozuoxiansen換成你本身的,而後進入project目錄看看,已經有README.md文件了。

10、建立於合併分支

分支在實際中有什麼用呢?假設你準備開發一個新功能,可是須要兩週才能完成,第一週你寫了50%的代碼,若是馬上提交,因爲代碼還沒寫完,不完整的代碼庫會致使別人不能幹活了。若是等代碼所有寫完再一次提交,又存在丟失天天進度的巨大風險。

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

Git的分支是不同凡響的,不管建立、切換和刪除分支,Git在1秒鐘以內就能完成!不管你的版本庫是1個文件仍是1萬個文件。

第一步:建立dev分支,而後切換到dev分支:

[root@git gittest]# git checkout -b dev     --git checkout命令加上-b參數表示建立並切換分支
切換到一個新分支 'dev'
# 至關於如下兩條命令
[root@git gittest]# git branch dev             --建立分支
[root@git gittest]# git checkout dev         --切換分支
切換到分支 'dev'

第二步:用git branch命令查看當前分支

[root@git gittest]# git branch               --列出全部分支,當前分支前面會標一個*號
* dev
  master

第三步:在dev分支上正常提交

[root@git gittest]# echo "creating a new branch" >> README       --向README文件添加內容
[root@git gittest]# git add README                                                --提交
[root@git gittest]# git commit -m "branch test"
[dev e4fc3ca] branch test
 1 file changed, 1 insertion(+)

 [root@git gittest]# git checkout master                         --切換回master分支
切換到分支 'master'
您的分支與上游分支 'origin/master' 一致。

[root@git gittest]# cat README             --再查看README文件,剛纔添加的內容不見了!由於那個提交是在dev分支上,而master分支此刻的提交點並無變
##README file
##new add test

第四步:把dev分支的工做成果合併到master分支上

[root@git gittest]# git merge dev            --咱們把dev分支的工做成果合併到master分支上
更新 c973a69..e4fc3ca
Fast-forward
 README | 1 +
 1 file changed, 1 insertion(+)

[root@git gittest]# cat README 
##README file
##new add test
creating a new branch

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

第五步:合併完成後,就能夠放心地刪除dev分支了

[root@git gittest]# git branch -d dev     --刪除dev分支
已刪除分支 dev(曾爲 e4fc3ca)。

[root@git gittest]# git branch                --刪除後,查看branch,就只剩下master分支了
* master

由於建立、合併和刪除分支很是快,因此咱們在使用分支完成某個任務時,合併後再刪掉分支,這和直接在master分支上工做效果是同樣的,但過程更安全。

相關文章
相關標籤/搜索