$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
因為Git是分布式版本控制系統,所以,每個機器都必須自報家門:你的名字和Email地址。你也許會擔心,如果有人故意冒充別人怎么辦?這個不必擔心,首先我們相信大家都是善良無知的群眾,其次,真的有冒充的也是有辦法可查的。
注意git config
命令的--global
參數,用了這個參數,表示你這臺機器上所有的Git倉庫都會使用這個配置,當然也可以對某個倉庫指定不同的用戶名和Email地址。
?
?
什么是版本庫呢?版本庫又名倉庫,英文名repository,你可以簡單理解成一個目錄,這個目錄里面的所有文件都可以被Git管理起來,每個文件的修改、刪除,Git都能跟蹤,以便任何時刻都可以追蹤歷史,或者在將來某個時刻可以“還原”。
所以,創建一個版本庫非常簡單,首先,選擇一個合適的地方,創建一個空目錄:
$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
pwd
命令用于顯示當前目錄。在我的Mac上,這個倉庫位于/Users/michael/learngit
。
如果你使用Windows系統,為了避免遇到各種莫名其妙的問題,請確保目錄名(包括父目錄)不包含中文。
第二步,通過git init
命令把這個目錄變成Git可以管理的倉庫:
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/
瞬間Git就把倉庫建好了,而且告訴你是一個空的倉庫(empty Git repository),細心的讀者可以發現當前目錄下多了一個.git
的目錄,這個目錄是Git來跟蹤管理版本庫的,沒事千萬不要手動修改這個目錄里面的文件,不然改亂了,就把Git倉庫給破壞了。
如果你沒有看到.git
目錄,那是因為這個目錄默認是隱藏的,用ls -ah
命令就可以看見。
?
git? diff 查看修改
在實際工作中,我們腦子里怎么可能記得一個幾千行的文件每次都改了什么內容,不然要版本控制系統干什么。版本控制系統肯定有某個命令可以告訴我們歷史記錄,在Git中,我們用git log
命令查看:
$ git log commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 21:06:15 2018 +0800append GPLcommit e475afc93c209a690c39c13a46716e8fa000c366 Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 21:03:36 2018 +0800add distributedcommit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 20:59:18 2018 +0800 wrote a readme file
git log
命令顯示從最近到最遠的提交日志,我們可以看到3次提交,最近的一次是append GPL
,上一次是add distributed
,最早的一次是wrote a readme file
。
如果嫌輸出信息太多,看得眼花繚亂的,可以試試加上--pretty=oneline
參數:
$ git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append GPL
e475afc93c209a690c39c13a46716e8fa000c366 add distributed
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file
在Git中,總是有后悔藥可以吃的。當你用$ git reset --hard HEAD^
回退到add distributed
版本時,再想恢復到append GPL
,就必須找到append GPL
的commit id。Git提供了一個命令git reflog
用來記錄你的每一次命令:
?
?
要關聯一個遠程庫,使用命令git remote add origin git@server-name:path/repo-name.git
;
關聯后,使用命令git push -u origin master
第一次推送master分支的所有內容;
此后,每次本地提交后,只要有必要,就可以使用命令git push origin master
推送最新修改;
分布式版本系統的最大好處之一是在本地工作完全不需要考慮遠程庫的存在,也就是有沒有聯網都可以正常工作,而SVN在沒有聯網的時候是拒絕干活的!當有網絡的時候,再把本地提交推送一下就完成了同步,真是太方便了!
?
創建與合并分支
在版本回退里,你已經知道,每次提交,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
分支:
$ 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
* devmaster
git branch
命令會列出所有分支,當前分支前面會標一個*
號。
然后,我們就可以在dev
分支上正常提交,比如對readme.txt做個修改,加上一行:
Creating a new branch is quick.
然后提交:
$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test1 file changed, 1 insertion(+)
現在,dev
分支的工作完成,我們就可以切換回master
分支:
$ git checkout master
Switched to branch 'master'
切換回master
分支后,再查看一個readme.txt文件,剛才添加的內容不見了!因為那個提交是在dev
分支上,而master
分支此刻的提交點并沒有變:
現在,我們把dev
分支的工作成果合并到master
分支上:
$ git merge dev
Updating d46f35e..b17d20e
Fast-forwardreadme.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 b17d20e).
刪除后,查看branch
,就只剩下master
分支了:
$ git branch
* master
因為創建、合并和刪除分支非常快,所以Git鼓勵你使用分支完成某個任務,合并后再刪掉分支,這和直接在master
分支上工作效果是一樣的,但過程更安全。
?
創建與合并分支
在版本回退里,你已經知道,每次提交,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
分支:
$ 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
* devmaster
git branch
命令會列出所有分支,當前分支前面會標一個*
號。
然后,我們就可以在dev
分支上正常提交,比如對readme.txt做個修改,加上一行:
Creating a new branch is quick.
然后提交:
$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test1 file changed, 1 insertion(+)
現在,dev
分支的工作完成,我們就可以切換回master
分支:
$ git checkout master
Switched to branch 'master'
切換回master
分支后,再查看一個readme.txt文件,剛才添加的內容不見了!因為那個提交是在dev
分支上,而master
分支此刻的提交點并沒有變:
現在,我們把dev
分支的工作成果合并到master
分支上:
$ git merge dev
Updating d46f35e..b17d20e
Fast-forwardreadme.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 b17d20e).
刪除后,查看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.txt
最后一行,改為:
Creating a new branch is quick AND simple.
在feature1
分支上提交:
$ git add readme.txt$ git commit -m "AND simple"
[feature1 14096d0] AND simple 1 file changed, 1 insertion(+), 1 deletion(-)
切換到master
分支:
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.(use "git push" to publish your local commits)
Git還會自動提示我們當前master
分支比遠程的master
分支要超前1個提交。
在master
分支上把readme.txt
文件的最后一行改為:
Creating a new branch is quick & simple.
提交:
$ git add readme.txt
$ git commit -m "& simple"
[master 5dc6824] & simple1 file changed, 1 insertion(+), 1 deletion(-)
現在,master
分支和feature1
分支各自都分別有新的提交,變成了這樣:
這種情況下,Git無法執行“快速合并”,只能試圖把各自的修改合并起來,但這種合并就可能會有沖突,我們試試看:
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result.
果然沖突了!Git告訴我們,readme.txt
文件存在沖突,必須手動解決沖突后再提交。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.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 cf810e4] conflict fixed
現在,master
分支和feature1
分支變成了下圖所示:
用帶參數的git log
也可以看到分支的合并情況:
$ git log --graph --pretty=oneline --abbrev-commit
* cf810e4 (HEAD -> master) conflict fixed
|\
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append GPL * e475afc add distributed * eaadf4e wrote a readme file
最后,刪除feature1
分支:
$ git branch -d feature1
Deleted branch feature1 (was 14096d0).