天天看點

Git-github-實用筆記(上)

Git-版本管理工具簡介

版本管理工具的作用

1、備份檔案

2、記錄曆史

3、多端共享

4、回到曆史檔案

5、友善團隊開發

Git-github-實用筆記(上)

集中式和分布式;集中式需要中心伺服器存放,連網;分布式不需要連網既可以快速擷取檔案;github程式員托管網站,軟體社群

Git下載下傳和安裝

GitHub官網-->Find out more-->http://www.bootcss.com/p/git-guide/-->下載下傳Git(Hub)-->預設安裝

建立倉庫

選擇一個合适的地方,建立一個空目錄:

d:                   //選擇d盤操作<code class="ruby">
mkdir project        //在d盤新</code><code class="ruby"></code><code class="ruby"></code>建立project檔案夾
           
Git-github-實用筆記(上)

通過git init指令把這個目錄變成Git可以管理的倉庫:

git init           //輸入git init 建立新的 git 倉庫。
           

可以發現目前目錄下多了一個.git的目錄,這個目錄是Git來跟蹤管理版本庫的,沒事千萬不要手動修改這個目錄裡面的檔案,不然改亂了,就把Git倉庫給破壞了。

建立成功可以把自己測試的demo放到裡面

開始添加檔案吧

用指令git add告訴Git,把檔案添加到倉庫:

git add <filename>
git add *
           

執行上面的指令,沒有任何顯示,這就對了,Unix的哲學是“沒有消息就是好消息”,說明添加成功。

用指令

git commit

告訴Git,把檔案送出到倉庫:

這是 git 基本工作流程的第一步;使用如下指令以實際送出改動:

git commit -m "代碼送出資訊"
           
Git-github-實用筆記(上)

現在,你的改動已經送出到了 HEAD,但是還沒到你的遠端倉庫。

簡單解釋一下git commit指令,-m後面輸入的是本次送出的說明,可以輸入任意内容,當然最好是有意義的,這樣你就能從曆史記錄裡友善地找到改動記錄。

時光穿梭

我們已經成功地添加并送出了一個test.html檔案,現在,是時候繼續工作了,于是,我們繼續修改test.html檔案

現在,運作git status指令看看結果:

git status
           
Git-github-實用筆記(上)

git status指令可以讓我們時刻掌握倉庫目前的狀态,上面的指令告訴我們,readme.txt被修改過了,但還沒有準備送出的修改。

雖然Git告訴我們test.html檔案被修改了,但是我想要看修改了具體内容,或者我出去幾天,回來時記不清怎麼修改的,這個時候用git diff這個指令看看:

git diff
           
Git-github-實用筆記(上)

知道了修改後,再把它送出到倉庫就放心多了,送出修改和送出新檔案是一樣的兩步,第一步是

git add

git add test.html
//擷取全部把它們添加到暫存區<code>git add *</code>
           

同樣沒有任何輸出。在執行第二步

git commit

之前,我們再運作

git status

看看目前倉庫的狀态:

Git-github-實用筆記(上)

git status

告訴我們,将要被送出的修改包括test.html,下一步,就可以放心地送出了:

git commit -m "add test"
           
Git-github-實用筆記(上)

送出後,我們再用

git status

指令看看倉庫的目前狀态:

Git-github-實用筆記(上)

Git告訴我們目前沒有需要送出的修改,而且,工作目錄是幹淨(working directory clean)的。

要随時掌握工作區的狀态,使用git status指令。

如果git status告訴你有檔案被修改過,用git diff可以檢視修改内容。

版本回退

我們可以多次修改多次

commit

通過

git log

指令檢視修改

commit

的曆史記錄

Git-github-實用筆記(上)

你看到的一大串類似

3628164...882e1e0

的是

commit id

(版本号),和SVN不一樣,Git的

commit id

不是1,2,3……遞增的數字,而是一個SHA1計算出來的一個非常大的數字,用十六進制表示,而且你看到的

commit id

和我的肯定不一樣,以你自己的為準。為什麼

commit id

需要用這麼一大串數字表示呢?因為Git是分布式的版本控制系統,後面我們還要研究多人在同一個版本庫裡工作,如果大家都用1,2,3……作為版本号,那肯定就沖突了。

每送出一個新版本,實際上Git就會把它們自動串成一條時間線。如果使用可視化工具檢視Git曆史,就可以更清楚地看到送出曆史的時間線:

通過

gitk

指令 打開内建的圖形化 git:

Git-github-實用筆記(上)

啟動時光穿梭機,準備把test.html回退到上一個版本,也就是“hello”的那個版本,怎麼做

首先,Git必須知道目前版本是哪個版本,在Git中,用

HEAD

表示目前版本,也就是最新的送出

3628164...882e1e0

(注意我的送出ID和你的肯定不一樣),上一個版本就是

HEAD^

,上上一個版本就是

HEAD^^

,當然往上100個版本寫100個

^

比較容易數不過來,是以寫成

HEAD~100

現在,我們要把目前版本回退到上一個版本“hello”,就可以使用

git reset

指令:

git reset --hard HEAD^
           

還可以繼續回退到上一個版本

wrote a readme file

,不過且慢,然我們用

git log

再看看現在版本庫的狀态:

Git-github-實用筆記(上)

最新的那個版本

已經看不到了!好比你從21世紀坐時光穿梭機來到了19世紀,想再回去已經回不去了 這可咋辦

辦法其實還是有的,隻要上面的指令行視窗還沒有被關掉,你就可以順着往上找啊找啊,于是就可以指定回到未來的某個版本:

git reset --hard 47d1
           
Git-github-實用筆記(上)

版本号沒必要寫全,前幾位就可以了,Git會自動去找。當然也不能隻寫前一兩位,因為Git可能會找到多個版本号,就無法确定是哪一個了。

哈哈,我又回到21新世紀了

現在,你回退到了某個版本,關掉了電腦,第二天早上就後悔了,想恢複到新版本怎麼辦?找不到新版本的

commit id

怎麼辦?

在Git中,總是有後悔藥可以吃的。當你用

$ git reset --hard HEAD^

回退到

19世紀

版本時,再想恢複到

21世紀

就必須找到

21世紀

的commit id。Git提供了一個指令

git reflog

用來記錄你的每一次指令:

git reflog
           
Git-github-實用筆記(上)

終于舒了口氣,第一行顯示

21世紀

的commit id是

47d1

,現在,你又可以乘坐時光機回到未來了。

Git-github-實用筆記(上)

HEAD指向的版本就是目前版本,是以,Git允許我們在版本的曆史之間穿梭,使用指令git reset --hard commit_id。

穿梭前,用git log可以檢視送出曆史,以便确定要回退到哪個版本。

要重返未來,用git reflog檢視指令曆史,以便确定要回到未來的哪個版本。

工作區和暫存區

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

先來看名詞解釋。

工作區(Working Directory)

就是你在電腦裡能看到的目錄,比如我的project檔案夾就是一個工作區:

Git-github-實用筆記(上)

版本庫(Repository)

工作區有一個隐藏目錄

.git

,這個不算工作區,而是Git的版本庫。

Git的版本庫裡存了很多東西,其中最重要的就是稱為stage(或者叫index)的暫存區,還有Git為我們自動建立的第一個分支

master

,以及指向

master

的一個指針叫

HEAD

Git-github-實用筆記(上)

分支和

HEAD

的概念我們以後再講。

前面講了我們把檔案往Git版本庫裡添加的時候,是分兩步執行的:

第一步是用

git add

把檔案添加進去,實際上就是把檔案修改添加到暫存區;

第二步是用

git commit

送出更改,實際上就是把暫存區的所有内容送出到目前分支。

因為我們建立Git版本庫時,Git自動為我們建立了唯一一個

master

分支,是以,現在,

git commit

就是往

master

分支上送出更改。

你可以簡單了解為,需要送出的檔案修改通通放到暫存區,然後,一次性送出暫存區的所有修改。

現在,我們再練習一遍,先對

test.html

做個修改,比如加上一行内容:

然後,在工作區新增一個

LICENSE

.txt文本檔案(内容随便寫)。

先用

git status

檢視一下狀态:

Git-github-實用筆記(上)

Git非常清楚地告訴我們,

test.html

被修改了,而

LICENSE.txt

還從來沒有被添加過,是以它的狀态是

Untracked

現在,使用兩次指令

git add

,把

readme.txt

LICENSE

都添加後,用

git status

再檢視一下:

Git-github-實用筆記(上)

現在,暫存區的狀态就變成這樣了:

Git-github-實用筆記(上)

是以,

git add

指令實際上就是把要送出的所有修改放到暫存區(Stage),然後,執行

git commit

就可以一次性把暫存區的所有修改送出到分支。

git commit -m "works"

[master 582b8f5] works
 3 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 LICENSE.txt
 create mode 100644 test1.html
           

一旦送出後,如果你又沒有對工作區做任何修改,那麼工作區就是“幹淨”的:

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

現在版本庫變成了這樣,暫存區就沒有任何内容了:

Git-github-實用筆記(上)

暫存區是Git非常重要的概念,弄明白了暫存區,就弄明白了Git的很多操作到底幹了什麼。

管理修改

為什麼Git比其他版本控制系統設計得優秀,因為Git跟蹤并管理的是修改,而非檔案。

什麼是修改?比如你新增了一行,這就是一個修改,删除了一行,也是一個修改,更改了某些字元,也是一個修改,删了一些又加了一些,也是一個修改,甚至建立一個新檔案,也算一個修改。

為什麼說Git管理的是修改,而不是檔案呢?我們還是做實驗。第一步,對test.html做一個修改,比如加一行内容:

然後,添加:

git add test.html
<pre><code class="ruby">git status</code>
           

On branch master

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

        modified:   test.html

然後,再修改test.html:

送出:

git commit -m "git tracks changes"
[master 6f7f25b] git tracks changes
 1 file changed, 1 insertion(+), 1 deletion(-)
           

送出後,再看看狀态:

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:   test.html

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 -- test.html

指令可以檢視工作區和版本庫裡面最新版本的差別:

git diff HEAD -- test.html
diff --git a/test.html b/test.html
index c90b241..c4ed831 100644
--- a/test.html
+++ b/test.html
@@ -5,6 +5,6 @@
        <title>Document</title>
 </head>
 <body>
-       hoell ! !  my huang
+       hoell ! !  my huang jipeng
 </body>
 </html>
\ No newline at end of file
           

可見,第二次修改确實沒有被送出。

那怎麼送出第二次修改呢?你可以繼續

git add

git commit

,也可以别着急送出第一次修改,先

git add

第二次修改,再

git commit

,就相當于把兩次修改合并後一塊送出了:

第一次修改 ->

git add

-> 第二次修改 ->

git add

->

git commit

現在,你又了解了Git是如何跟蹤修改的,每次修改,如果不

add

到暫存區,那就不會加入到

commit

中。

撤銷修改

如果在準備送出前,發現工作中有錯誤我們可以很容易修正

既然錯誤發現得很及時,就可以很容易地糾正它。你可以删掉最後一行,手動把檔案恢複到上一個版本的狀态。如果用

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:   test.html

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

你可以發現,Git會告訴你,

git checkout -- file

可以丢棄工作區的修改:

$ git checkout -- test.html
           

指令

git checkout -- test.html

意思就是,把test.html

檔案在工作區的修改全部撤銷,這裡有兩種情況:

一種是

test.html

自修改後還沒有被放到暫存區,現在,撤銷修改就回到和版本庫一模一樣的狀态;

一種是test.html已經添加到暫存區後,又作了修改,現在,撤銷修改就回到添加到暫存區後的狀态。

總之,就是讓這個檔案回到最近一次

git commit

git add

時的狀态。

檔案内容自然就會複原。

git checkout -- file

指令中的

--

很重要,沒有

--

,就變成了“切換到另一個分支”的指令,我們在後面的分支管理中會再次遇到

git checkout

指令。

現在假定是淩晨3點,你不但寫了一些胡話,還

git add

到暫存區了:

git add test.html
           

慶幸的是,在

commit

之前,你發現了這個問題。用

git status

檢視一下,修改隻是添加到了暫存區,還沒有送出:

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

        modified:   test.html
           

Git同樣告訴我們,用指令

git reset HEAD file

可以把暫存區的修改撤銷掉(unstage),重新放回工作區:

G:\test3>git reset HEAD test.html
Unstaged changes after reset:
M       test.html
           

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.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
           

現在,假設你不但改錯了東西,還從暫存區送出到了版本庫,怎麼辦呢?還記得版本回退一節嗎?可以回退到上一個版本。不過,這是有條件的,就是你還沒有把自己的本地版本庫推送到遠端。還記得Git是分布式版本控制系統嗎?我們後面會講到遠端版本庫,一旦你把“stupid boss”送出推送到遠端版本庫,你就真的慘了……

場景1:當你改亂了工作區某個檔案的内容,想直接丢棄工作區的修改時,用指令

git checkout -- file

場景2:當你不但改亂了工作區某個檔案的内容,還添加到了暫存區時,想丢棄修改,分兩步,第一步用指令

git reset HEAD file

,就回到了場景1,第二步按場景1操作。

場景3:已經送出了不合适的修改到版本庫時,想要撤銷本次送出,參考版本回退一節,不過前提是沒有推送到遠端庫。

删除檔案

在Git中,删除也是一個修改操作,我們實戰一下,先添加一個新檔案test1.html到Git并且送出:

G:\test3>git add test1.html

G:\test3>git commit -m "add test1.html"
[master b42eb7c] add test1.html
 1 file changed, 1 insertion(+), 1 deletion(-)
           

一般情況下,你通常直接在檔案管理器中把沒用的檔案删了,或者用

rm

指令删了:

G:\test3>del test1.html
           

這個時候,Git知道你删除了檔案,是以,工作區和版本庫就不一緻了,

git status

指令會立刻告訴你哪些檔案被删除了:

G:\test3>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)

        modified:   test.html
        deleted:    test1.html

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

現在你有兩個選擇,一是确實要從版本庫中删除該檔案,那就用指令

git rm

删掉,并且

git commit

G:\test3>git rm test1.html
rm 'test1.html'
G:\test3>git commit -m "remove test1.html"
[master dbc1732] remove test1.html
 1 file changed, 10 deletions(-)
 delete mode 100644 test1.html
           

現在,檔案就從版本庫中被删除了。

另一種情況是删錯了,因為版本庫裡還有呢,是以可以很輕松地把誤删的檔案恢複到最新版本:

git checkout -- test1.html
           

指令

git rm

用于删除一個檔案。如果一個檔案已經被送出到版本庫,那麼你永遠不用擔心誤删,但是要小心,你隻能恢複檔案到最新版本,你會丢失 最近一次送出後你修改的内容。

遠端倉庫

Git是分布式版本控制系統,同一個Git倉庫,可以分布到不同的機器上。怎麼分布呢?最早,肯定隻有一台機器有一個原始版本庫,此後,别的機器可以“克隆”這個原始版本庫,而且每台機器的版本庫其實都是一樣的,并沒有主次之分。

SSH

你擁有了一個 GitHub 賬号之後,就可以自由的 clone 或者下載下傳其他項目,也可以建立自己的項目,但是你沒法送出代碼。仔細想想也知道,肯定不可能随意就能送出代碼的,如果随意可以送出代碼,那麼 GitHub 上的項目豈不亂了套了,是以送出代碼之前一定是需要某種授權的,而 GitHub 上一般都是基于 SSH 授權的。

那麼什麼是 SSH 呢?

簡單點說,SSH是一種網絡協定,用于計算機之間的加密登入。目前是每一台 Linux 電腦的标準配置。而大多數 Git 伺服器都會選擇使用 SSH 公鑰來進行授權,是以想要在 GitHub 送出代碼的第一步就是要先添加 SSH key 配置。

生成SSH key

Linux 與 Mac 都是預設安裝了 SSH ,而 Windows 系統安裝了 Git Bash 應該也是帶了 SSH 的。大家可以在終端(win下在 Git Bash 裡)輸入 ssh 如果出現以下提示證明你本機已經安裝 SSH, 否則請搜尋自行安裝下。

Git-github-實用筆記(上)

緊接着輸入 ssh-keygen -t rsa ,什麼意思呢?就是指定 rsa 算法生成密鑰,接着連續三個Enter鍵(不需要輸入密碼),然後就會生成兩個檔案 id_rsa 和 id_rsa.pub ,而 id_rsa 是密鑰,id_rsa.pub 就是公鑰。這兩檔案預設分别在如下目錄裡生成:

Linux/Mac 系統 在 ~/.ssh 下,win系統在 /c/Documents and Settings/username/.ssh 下,都是隐藏檔案,相信你們有辦法檢視的。

接下來要做的是把 id_rsa.pub 的内容添加到 GitHub 上,這樣你本地的 id_rsa 密鑰跟 GitHub 上的 id_rsa.pub 公鑰進行配對,授權成功才可以送出代碼。

GitHub 上添加 SSH key

第一步先在 GitHub 上的設定頁面,點選最左側 SSH and GPG keys :

Git-github-實用筆記(上)

然後點選右上角的 New SSH key 按鈕:

Git-github-實用筆記(上)

需要做的隻是在 Key 那欄把 id_rsa.pub 公鑰檔案裡的内容複制粘貼進去就可以了(上述示例為了安全粘貼的公鑰是無效的),Title 那欄不需要填寫,點選 Add SSH key 按鈕就ok了。

SSH key 添加成功之後,輸入 ssh -T [email protected] 進行測試,如果出現以下提示證明添加成功了。

Git-github-實用筆記(上)

為什麼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”按鈕,建立一個新的倉庫:

Git-github-實用筆記(上)

在Repository name填入test3,其他保持預設設定,點選“Create repository”按鈕,就成功地建立了一個新的Git倉庫:

Git-github-實用筆記(上)

目前,在GitHub上的這個

learngit

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

現在,我們根據GitHub的提示,在本地的

learngit

倉庫下運作指令:

如果你還沒有克隆現有倉庫,并欲将你的倉庫連接配接到某個遠端伺服器,你可以使用如下指令添加:

git remote add origin <server>

如此你就能夠将你的改動推送到所添加的伺服器上去了。

//首先先連結下遠端的git庫
G:\test3>git remote add origin [email protected]:huanghanzhilian/test3.git
           

下一步,就可以把本地庫的所有内容推送到遠端庫上:

G:\test3>git push -u origin master
Counting objects: 22, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (18/18), done.
Writing objects: 100% (22/22), 1.77 KiB | 0 bytes/s, done.
Total 22 (delta 8), reused 0 (delta 0)
remote: Resolvin
           

把本地庫的内容推送到遠端,用

git push

指令,實際上是把目前分支

master

推送到遠端。

由于遠端庫是空的,我們第一次推送

master

分支時,加上了

-u

參數,Git不但會把本地的

master

分支内容推送的遠端新的

master

分支,還會把本地的

master

分支和遠端的

master

分支關聯起來,在以後的推送或者拉取時就可以簡化指令。

推送成功後,可以立刻在GitHub頁面中看到遠端庫的内容已經和本地一模一樣:

Git-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 [email protected]:path/repo-name.git

關聯後,使用指令

git push -u origin master

第一次推送master分支的所有内容;

此後,每次本地送出後,隻要有必要,就可以使用指令

git push origin master

推送最新修改;

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

從遠端庫克隆

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

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

首先,登陸GitHub,建立一個新的倉庫,名字叫

gitskills

Git-github-實用筆記(上)

我們勾選

Initialize this repository with a README

,這樣GitHub會自動為我們建立一個

README.md

檔案。建立完畢後,可以看到

README.md

檔案:

現在,遠端庫已經準備好了,下一步是用指令

git clone

克隆一個本地庫:

G:\>git clone [email protected]:huanghanzhilian/gitskills.git
Cloning into 'gitskills'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
           

注意把Git庫的位址換成你自己的,然後進入

gitskills

目錄看看,已經有

README.md

檔案了

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

你也許還注意到,GitHub給出的位址不止一個,還可以用

https://github.com/michaelliao/gitskills.git

這樣的位址。實際上,Git支援多種協定,預設的

git://

使用ssh,但也可以使用

https

等其他協定。

使用

https

除了速度慢以外,還有個最大的麻煩是每次推送都必須輸入密碼,但是在某些隻開放http端口的公司内部就無法使用

ssh

協定而隻能用

https

要克隆一個倉庫,首先必須知道倉庫的位址,然後使用

git clone

指令克隆。

Git支援多種協定,包括

https

,但通過

ssh

支援的原生

git

協定速度最快。

繼續閱讀