Git的使用
来源:互联网 发布:外观设计用什么软件 编辑:程序博客网 时间:2024/05/30 19:33
今天开始着手学习一下版本控制工具,市面上比较流行的版本控制一个Git一个SVN。这两种一个是分布式的一个是集中式,最后我优先选择学习Git毕竟它是出自Linux社区,从大二开始使用Ubuntu也快一年多了,确实开始对Linux有了情节。废话不多说了,着手开始学习Git吧。
安装 git :
sudo apt-get install git
创建版本库:
选择一个合适的地方,创建一个空目录:
wang@hadoop ~ $ mkdir myGitRepository wang@hadoop ~ $ cd myGitRepository/ wang@hadoop ~/myGitRepository $ git init Initialized empty Git repository in /home/wang/myGitRepository/.git/ wang@hadoop ~/myGitRepository $
如上,在某目录下执行 git init即可把当前目录作为版本库,此时会在当前目录下生成一个git的隐藏目录,这个目录是Git来跟踪管理版本库的,没事千万不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了。
把文件添加到版本库:
将编写的helloWorld.txt(内容仅一行hello world)导入到myGitRepository目录下,即我们创建版本库的目录下。
执行命令:
git add helloWorld.txt
用命令git add告诉Git,把文件添加到仓库.
然后用命令git commit告诉Git,把文件提交到仓库:
git commit -m "此处写文件说明" [master (root-commit) cb926e7] xxxx 1 file changed, 1 insertions(+) create mode 100644 helloWorld.txt
说明: git commit命令,-m后面输入的是本次提交的说明.
git commit命令执行成功后会告诉你,1个文件被改动(我们新添加的helloWorld.txt文件),插入了1行内容(helloWorld.txt有1行内容)。
为什么Git添加文件需要add,commit一共两步呢?因为commit可以一次提交很多文件,所以你可以多次add不同的文件,比如:
$ git add file1.txt$ git add file2.txt file3.txt$ git commit -m "add 3 files."
我们已经成功地添加并提交了一个helloWorld.txt文件,现在,是时候继续工作了,于是,我们继续修改helloworld.txt文件,改成如下内容:
hello world6666
现在,运行git status命令看看结果:
wang@hadoop ~/myGitRepository $ git statusOn branch masterChanges 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: helloworld.txtno changes added to commit (use "git add" and/or "git commit -a")
git status命令可以让我们时刻掌握仓库当前的状态,上面的命令告诉我们,helloWorld.txt被修改过了,但还没有准备提交的修改。
虽然Git告诉我们readme.txt被修改了,但如果要看看具体修改了什么内容使用 git diff:
wang@hadoop ~/myGitRepository $ git diff helloworld.txtdiff --git a/helloworld.txt b/helloworld.txtindex 31e0fce..eae218c 100644--- a/helloworld.txt+++ b/helloworld.txt@@ -1 +1 @@-helloworld+helloworld66666
可以从上面的命令输出看到,我们把第一行helloworld改为helloworld66666
提交修改和提交新文件是一样的两步,第一步是git add:
git add helloWorld.txt
同样没有任何输出。在执行第二步git commit之前,我们再运行git status看看当前仓库的状态:
wang@hadoop ~/myGitRepository $ git statusOn branch masterChanges to be committed: (use "git reset HEAD <file>..." to unstage) modified: helloworld.txt
git status告诉我们,将要被提交的修改包括helloworld.txt,下一步,就可以放心地提交了:
wang@hadoop ~/myGitRepository $ git commit -m "第二次提交helloworld"[master 1fe345a] 第二次提交helloworld 1 file changed, 1 insertion(+), 1 deletion(-)
版本回退:
每当你觉得文件修改到一定程度的时候,就可以“保存一个快照”,这个快照在Git中被称为commit。一旦你把文件改乱了,或者误删了文件,还可以从最近的一个commit恢复,然后继续工作,而不是把几个月的工作成果全部丢失。
现在,我们helloWorld.txt文件一共有两个版本被提交到Git仓库里了:
通过执行 git log命令可以看到具体不同的版本中有那些内容被改动了:
wang@hadoop ~/myGitRepository $ git logcommit 1fe345a47b9b3a3d236f22dd9525cb9465536f98Author: wangxi <1165196813@qq.com>Date: Sun Jan 31 16:10:18 2016 +0800 第二次提交helloworldcommit 3925bfb2326f1550a3dd7861fd965b54249edf39Author: wangxi <1165196813@qq.com>Date: Sun Jan 31 15:59:36 2016 +0800 第一次提交helloworld
git log命令显示从最近到最远的提交日志. 其中3925bfb2326f1550a3dd7861fd965b54249edf39是版本号。
好了,现在我们准备把readme.txt回退到上一个版本,也就是“第一次提交helloworld”的那个版本,怎么做呢?
首先,Git必须知道当前版本是哪个版本,在Git中,用HEAD表示当前版本,也就是最新的提交1fe345a47b…49edf39,上一个版本就是HEAD^,上上一个版本就是HEAD^^,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100。
现在,我们要把当前版本回退到上一个版本,就可以使用git reset命令:
wang@hadoop ~/myGitRepository $ git reset --hard HEAD^HEAD is now at 3925bfb 第一次提交helloworld
现在你打开helloWorld.txt就会发现,内容是helloworld。。
此时你打开git log:
wang@hadoop ~/myGitRepository $ git logcommit 3925bfb2326f1550a3dd7861fd965b54249edf39Author: wangxi <1165196813@qq.com>Date: Sun Jan 31 15:59:36 2016 +0800 第一次提交helloworld
此时第二次那个版本已经不见了,如果我们后悔,想要第二个版本,此时只要有其版本号即可:
wang@hadoop ~/myGitRepository $ git reset --hard 1fe345a47b9b3aHEAD is now at 1fe345a 第二次提交helloworld
版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。此时打开helloWorld.txt会发现文本内容是第二次的helloWorld66666
Git的版本回退速度非常快,因为Git在内部有个指向当前版本的HEAD指针,当你回退版本的时候,Git仅仅是改变HEAD的指向。然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号,你就把当前版本定位在哪。
Git提供了一个命令git reflog用来记录你的每一次命令,这个命令通常用来查找版本号来让你可以有后悔药吃。
工作区和暂存区:
Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。
先来看名词解释。
工作区(Working Directory)
就是你在电脑里能看到的目录,比如我的~/myGitRepository文件夹就是一个工作区:
版本库(Repository)
工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。
git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。
前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的:
第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;
第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。
你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。
现在我们再次修改 helloWorld.txt 并在工作区下增加一个listener.txt内容随便写。
执行两个 git add添加上面两个文件后 ,通过git status查看状态:
wang@hadoop ~/myGitRepository $ git statusOn branch masterChanges to be committed: (use "git reset HEAD <file>..." to unstage) modified: helloworld.txt new file: listener.txt
现在,此时这两个文件在缓存区.现在当你执行
wang@hadoop ~/myGitRepository $ git commit -m "测试暂存区"[master 3986862] 测试暂存区 2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 listener.txt
一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的:
$ git status On branch masternothing to commit (working directory clean)
为什么Git比其他版本控制系统设计得优秀,因为Git跟踪并管理的是修改,而非文件。这也就是为什么git可以很快速的进行回退。
撤销更改:
git checkout – file可以丢弃工作区的修改
命令git checkout – helloWorld.txt意思就是,把helloWorld.txt文件在工作区的修改全部撤销,这里有两种情况:
一种是helloWorld.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
一种是helloWorld.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit或git add时的状态。
git reset HEAD file 可以把暂存区的修改撤销掉(unstage),重新放回工作区:
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout – file。
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD file,就回到了场景1,第二步按场景1操作。
删除文件:
在Git中,删除也是一个修改操作,我们实战一下,先添加一个新文件test.txt到Git并且提交:
[master 94cdc44] add test.txt
1 file changed, 1 insertion(+)
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.txtno changes added to commit (use "git add" and/or "git commit -a")
现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm删掉,并且git commit:
$ git rm test.txtrm '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其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
远程仓库:
在给github添加了你的公钥后,关联本地仓库与Github。
git remote add origin XXXXX
xxxx表示你的Github的ssh路径,在github上复制即可。
与这条命令相反的操作:
git remote rm origin
添加后,远程库的名字就是origin,这是Git默认的叫法,也可以改成别的,但是origin这个名字一看就知道是远程库。
下一步,就可以把本地库的所有内容推送到远程库上:
git push -u origin master
把本地库的内容推送到远程,用git push命令,实际上是把当前分支master推送到远程。
由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。
推送成功后,可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样:
从现在起,只要本地作了提交,就可以通过命令:
$ git push origin master
把本地master分支的最新修改推送至GitHub,现在,你就拥有了真正的分布式版本库!
注意:如果你在github上创建了Repository时勾选Initialize this repository with a README 时,此时你的Repository会有个README.md,这是你去push代码无法成功(failed to push some refs to git)。出现错误的主要原因是github中的README.md文件不在本地代码目录中,可以通过如下命令进行代码合并【注:pull=fetch+merge]
git pull --rebase origin master
执行上面代码后可以看到本地代码库中多了README.md文件
此时push代码到githhub就不会有问题了。
从远程库克隆项目:
即使我们从零开发,那么最好的方式是先创建远程库,然后,从远程库克隆。
例如在github上有repository AndroidGitRepository在本地代码库中执行:
git clone git@github.com:JackmanGo/AndroidGitRepository.git
路径依然复制出自远程库中的SSH协议路径
wang@hadoop ~/myGitRepository $ git clone git@github.com:JackmanGo/AndroidGitRepository.gitCloning into 'AndroidGitRepository'...remote: Counting objects: 3, done.remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0Receiving objects: 100% (3/3), done.Checking connectivity... done.
这样这个项目便被克隆到了本地。
分支管理:
其他版本控制系统如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分支:
$ git checkout -b devSwitched to a new branch 'dev'
git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:
$ git branch dev$ git checkout devSwitched to branch 'dev'
然后,用git branch命令查看当前分支:
$ git branch* dev master
git branch命令会列出所有分支,当前分支前面会标一个*号。
然后,我们就可以在dev分支上正常提交,比如对helloWorld.txt做个修改,加上一行: Creating a new branch is quick.
然后提交:
$ git add helloWorld.txt $ git commit -m "branch test"[dev fec145a] branch test 1 file changed, 1 insertion(+)
现在,dev分支的工作完成,我们就可以切换回master分支:
$ git checkout masterSwitched to branch 'master'
切换回master分支后,再查看一个helloWorld.txt文件,刚才添加的内容不见了!因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:
现在,我们把dev分支的工作成果合并到master分支上:
$ git merge devUpdating d17efd8..fec145aFast-forward helloWorld.txt | 1 + 1 file changed, 1 insertion(+)
git merge命令用于合并指定分支到当前分支。合并后,再查看helloWorld.txt的内容,就可以看到,和dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。
当然,也不是每次合并都能Fast-forward,我们后面会讲其他方式的合并。
合并完成后,就可以放心地删除dev分支了:
$ git branch -d devDeleted branch dev (was fec145a).
删除后,查看branch,就只剩下master分支了:
$ git branch* master
因为创建、合并和删除分支非常快,所以Git鼓励你使用分支完成某个任务,合并后再删掉分支,这和直接在master分支上工作效果是一样的,但过程更安全。
解决不同分支的冲突:
准备新的feature1分支,继续我们的新分支开发:
$ git checkout -b feature1Switched 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 75a857c] AND simple 1 file changed, 1 insertion(+), 1 deletion(-)
切换到master分支:
$ git checkout masterSwitched to branch 'master'Your branch is ahead of 'origin/master' by 1 commit.
Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。
在master分支上把readme.txt文件的最后一行改为:
Creating a new branch is quick & simple.
提交:
$ git add readme.txt $ git commit -m "& simple"[master 400b400] & simple 1 file changed, 1 insertion(+), 1 deletion(-)
现在,master分支和feature1分支各自都分别有新的提交,变成了这样:
这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,我们试试看:
$ git merge feature1Auto-merging readme.txtCONFLICT (content): Merge conflict in readme.txtAutomatic 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. Unmerged paths: (use "git add/rm <file>..." as appropriate to mark resolution) both modified: readme.txtno 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.<<<<<<< HEADCreating 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 log也可以看到分支的合并情况:
$ git log --graph --pretty=oneline --abbrev-commit* 59bc1cb conflict fixed|\| * 75a857c AND simple* | 400b400 & simple|/* fec145a branch test...
最后,删除feature1分支:
$ git branch -d feature1Deleted branch feature1 (was 75a857c).
当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。
用git log –graph命令可以看到分支合并图。
分支管理策略
通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
下面我们实战一下–no-ff方式的git merge:
首先,仍然创建并切换dev分支:
$ git checkout -b devSwitched to a new branch 'dev'
修改helloWorld.txt文件,并提交一个新的commit:
$ git add helloWorld.txt $ git commit -m "add merge"[dev 6224937] add merge 1 file changed, 1 insertion(+)
现在,我们切换回master:
$ git checkout masterSwitched to branch 'master'
准备合并dev分支,请注意–no-ff参数,表示禁用Fast forward:
$ git merge --no-ff -m "merge with no-ff" devMerge 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...
可以看到,不使用Fast forward模式,merge后就像这样:
软件开发中,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.txt#
并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?
幸好,Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
$ git stashSaved working directory and index state WIP on dev: 6224937 add mergeHEAD is now at 6224937 add merge
现在,用git status查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug,假定需要在master分支上修复,就从master创建临时分支:
$ git checkout masterSwitched to branch 'master'Your branch is ahead of 'origin/master' by 6 commits.$ git checkout -b issue-101Switched to a new branch 'issue-101'
现在修复bug,然后提交:
$ git add readme.txt $ git commit -m "fix bug 101"[issue-101 cc17032] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后,切换到master分支,并完成合并,最后删除issue-101分支:
$ git checkout masterSwitched to branch 'master'Your branch is ahead of 'origin/master' by 2 commits.$ git merge --no-ff -m "merged bug fix 101" issue-101Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)$ git branch -d issue-101Deleted branch issue-101 (was cc17032).
太棒了,原计划两个小时的bug修复只花了5分钟!现在,是时候接着回到dev分支干活了!
$ git checkout devSwitched to branch 'dev'$ git status# On branch devnothing to commit (working directory clean)
工作区是干净的,刚才的工作现场存到哪去了?用git stash list命令看看:
$ git stash liststash@{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.txt#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分支。
现在,你终于接到了一个新任务:开发代号为Vulcan的新功能,该功能计划用于下一代星际飞船。
于是准备开发:
$ git checkout -b feature-vulcanSwitched to a new branch '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 756d4af] add feature vulcan 1 file changed, 2 insertions(+) create mode 100644 vulcan.py
切回dev,准备合并:
$ git checkout dev
一切顺利的话,feature分支和bug分支是类似的,合并,然后删除。
但是,
就在此时,接到上级命令,因经费不足,新功能必须取消!
虽然白干了,但是这个分支还是必须就地销毁:
$ git branch -d feature-vulcanerror: 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-vulcanDeleted branch feature-vulcan (was 756d4af).
多人协助
当你从远程仓库克隆时,实际上Git自动把本地的master分支和远程的master分支对应起来了,并且,远程仓库的默认名称是origin。
要查看远程库的信息,用git remote:
或者,用git remote -v显示更详细的信息:
$ git remote -vorigin git@github.com:michaelliao/learngit.git (fetch)origin git@github.com:michaelliao/learngit.git (push)
上面显示了可以抓取和推送的origin的地址。如果没有推送权限,就看不到push的地址。
推送分支
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:
$ git push origin master
推送分支
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,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.gitCloning 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命令看看:
$ git branch* master
现在,你的小伙伴要在dev分支上开发,就必须创建远程origin的dev分支到本地,于是他用这个命令创建本地dev分支:
$ git checkout -b dev origin/dev
现在,他就可以在dev上继续修改,然后,时不时地把dev分支push到远程:
$ git commit -m "add /usr/bin/env"[dev 291bea8] add /usr/bin/env 1 file changed, 1 insertion(+)$ git push origin devCounting objects: 5, done.Delta compression using up to 4 threads.Compressing objects: 100% (2/2), done.Writing objects: 100% (3/3), 349 bytes, done.Total 3 (delta 0), reused 0 (delta 0)To git@github.com:michaelliao/learngit.git fc38031..291bea8 dev -> dev
你的小伙伴已经向origin/dev分支推送了他的提交,而碰巧你也对同样的文件作了修改,并试图推送:
$ git add hello.py $ git commit -m "add coding: utf-8"[dev bd6ae48] add coding: utf-8 1 file changed, 1 insertion(+)$ git push origin devTo git@github.com:michaelliao/learngit.git ! [rejected] dev -> dev (non-fast-forward)error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart. Merge the remote changes (e.g. 'git pull')hint: before pushing again.hint: See the 'Note about fast-forwards' in 'git push --help' for details.
推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,解决办法也很简单,Git已经提示我们,先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送:
$ git pullremote: Counting objects: 5, done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 3 (delta 0)Unpacking objects: 100% (3/3), done.From github.com:michaelliao/learngit fc38031..291bea8 dev -> origin/devThere 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 dev origin/<branch>
git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接:
$ git branch --set-upstream dev origin/devBranch dev set up to track remote branch dev from origin.
再pull:
$ git pullAuto-merging hello.pyCONFLICT (content): Merge conflict in hello.pyAutomatic 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 devCounting 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)To git@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的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。
在Git中打标签非常简单,首先,切换到需要打标签的分支上:
$ git branch* dev master$ git checkout masterSwitched to branch 'master'
然后,敲命令git tag 就可以打一个新标签:
$ git tag v1.0
可以用命令git tag查看所有标签:
$ git tagv1.0
默认标签是打在最新提交的commit上的。有时候,如果忘了打标签,比如,现在已经是周五了,但应该在周一打的标签没有打,怎么办?
方法是找到历史提交的commit id,然后打上就可以了:
$ git log --pretty=oneline --abbrev-commit6a5819e merged bug fix 101cc17032 fix bug 1017825a50 merge with no-ff6224937 add merge59bc1cb conflict fixed400b400 & simple75a857c AND simplefec145a branch testd17efd8 remove test.txt...
比方说要对add merge这次提交打标签,它对应的commit id是6224937,敲入命令:
$ git tag v0.9 6224937
再用命令git tag查看标签:
$ git tagv0.9v1.0
注意,标签不是按时间顺序列出,而是按字母排序的。可以用git show <tagname>
查看标签信息:
$ git show v0.9commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4Author: Michael Liao <askxuefeng@gmail.com>Date: Thu Aug 22 11:22:08 2013 +0800 add merge...
可以看到,v0.9确实打在add merge这次提交上。
还可以创建带有说明的标签,用-a指定标签名,-m指定说明文字:
$ git tag -a v0.1 -m "version 0.1 released" 3628164
用命令git show <tagname>
可以看到说明文字:
$ git show v0.1tag v0.1Tagger: Michael Liao <askxuefeng@gmail.com>Date: Mon Aug 26 07:28:11 2013 +0800version 0.1 releasedcommit 3628164fb26d48395383f8f31179f24e0882e1e0Author: Michael Liao <askxuefeng@gmail.com>Date: Tue Aug 20 15:11:49 2013 +0800 append GPL
如果标签打错了,也可以删除:
$ git tag -d v0.1Deleted tag 'v0.1' (was e078af9)
因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。
如果要推送某个标签到远程,使用命令git push origin <tagname>:
$ git push origin v1.0Total 0 (delta 0), reused 0 (delta 0)To git@github.com:michaelliao/learngit.git * [new tag] v1.0 -> v1.0
或者,一次性推送全部尚未推送到远程的本地标签:
$ git push origin --tagsCounting 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.9Deleted tag 'v0.9' (was 6224937)
然后,从远程删除。删除命令也是push,但是格式如下:
$ git push origin :refs/tags/v0.9To git@github.com:michaelliao/learngit.git - [deleted] v0.9
要看看是否真的从远程库删除了标签,可以登陆GitHub查看。
忽略特殊文件
有些时候,你必须把某些文件放到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.dbehthumbs.dbDesktop.ini
然后,继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录:
Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
加上你自己定义的文件,最终得到一个完整的.gitignore文件,内容如下:
# Windows:Thumbs.dbehthumbs.dbDesktop.ini# Python:*.py[cod]*.so*.egg*.egg-infodistbuild# My configurations:db.inideploy_key_rsa
最后一步就是把.gitignore也提交到Git,就完成了!当然检验.gitignore的标准是git status命令是不是说working directory clean。
使用Windows的童鞋注意了,如果你在资源管理器里新建一个.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 lastcommit adca45d317e6d8a4b23f9811c3d7b7f0f180bfe2Merge: bd6ae48 291bea8Author: Michael Liao <askxuefeng@gmail.com>Date: Thu Aug 22 22:49:22 2013 +0800merge & fix hello.py
配置文件
配置Git的时候,加上–global是针对当前用户起作用的,如果不加,那只针对当前的仓库起作用。
配置文件放哪了?每个仓库的Git配置文件都放在.git/config文件中:
别名就在[alias]后面,要删除别名,直接把对应的行删掉即可。
而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中。
- git的使用 git命令
- 【Git使用详解】Git的使用心得
- Git管理工具的使用
- git的使用
- git hub 的使用
- git工具的使用
- git的使用
- git的使用
- git的使用。
- git 的使用
- git的简单使用
- git的简单使用
- GIT的基本使用
- git 的使用
- git的使用
- git repo的使用
- git的使用
- git的使用
- 贪心 1
- WCF基础
- 三维空间——点线面关系
- 【Android】Android性能优化
- Network 【Charles 抓包(原理篇)】
- Git的使用
- 第三届蓝桥杯C/C++组第十题 取球游戏(博弈)
- mysql 严格模式 Strict Mode说明
- 虚幻4蓝图使用小技巧(更新)
- 第一章·第一节·创世之旅——面向对象建模方法之一
- 【Android进阶】Android面试题目整理与讲解
- web.xml load-on-startup
- 多用途互联网邮件扩展MIME
- Android Studio - no debuggable applications 的解决办法