Git使用
概述
-
Git 是一个开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。
-
Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
-
Git 与常用的版本控制工具 CVS, Subversion 等不同,它采用了分布式版本库的方式,不必服务器端软件支持。
-
https://github.com/ 全球最大的开源项目网站。
-
https://gitee.com/ 中国最大的开源项目网站。
Git 与 SVN 区别
Git 不仅仅是个版本控制系统,它也是个内容管理系统(CMS),工作管理系统等。
Git 与 SVN 区别点:
- 1、Git 是分布式的,SVN 不是:这是 Git 和其它非分布式的版本控制系统,例如 SVN,CVS 等,最核心的区别。
- 2、Git 把内容按元数据方式存储,而 SVN 是按文件:所有的资源控制系统都是把文件的元信息隐藏在一个类似 .svn、.cvs 等的文件夹里。
- 3、Git 分支和 SVN 的分支不同:分支在 SVN 中一点都不特别,其实它就是版本库中的另外一个目录。
- 4、Git 没有一个全局的版本号,而 SVN 有:目前为止这是跟 SVN 相比 Git 缺少的最大的一个特征。
- 5、Git 的内容完整性要优于 SVN:Git 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性,确保在遇到磁盘故障和网络问题时降低对版本库的破坏。
git安装
官方下载地址:https://git-scm.com/downloads
工作流程
一般的工作流程为:
1、克隆Git资源作为工作目录。
2、在克隆的资源上添加或修改文件。
3、查看修改并提交,并且可以撤回修改。
因为Git是分布式版本控制系统,所以,每台电脑都必须有一个自己的用户:提供名字和Email地址。
$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
基本概念及指令
版本库,版本库又名仓库,英文名repository,你可以简单理解成一个目录,这个目录里面的所有文件都可以被Git管理起来,每个文件的修改、删除,Git都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻可以“还原”。
所以,我们需要创建一个版本库,首先,选择一个合适的地方,创建一个空目录,在当前目录下打开git(右键Git Bash Here),使用git init
指令初始化git仓库。
瞬间Git就把仓库建好了,而且告诉你是一个空的仓库(empty Git repository),当前目录下多了一个.git的目录,这个目录是Git来跟踪管理版本库的。(该目录默认是隐藏的)
- 创建仓库命令
命令 | 说明 |
---|---|
git init |
初始化仓库 |
git clone |
拷贝一份远程仓库,也就是下载一个项目。 |
- 提交与修改
Git 的工作就是创建和保存你的项目的快照及与之后的快照进行对比。
命令 | 说明 |
---|---|
git add |
添加文件到仓库 |
git status |
查看仓库当前的状态,显示有变更的文件。 |
git diff |
比较文件的不同,即暂存区和工作区的差异。 |
git commit |
提交暂存区到本地仓库。 |
git reset |
回退版本。 |
git rm |
删除工作区文件。 |
git mv |
移动或重命名工作区文件。 |
- 提交日志
命令 | 说明 |
---|---|
git log |
查看历史提交记录 |
git blame |
以列表形式查看指定文件的历史修改记录 |
- 远程操作
命令 | 说明 |
---|---|
git remote |
远程仓库操作 |
git fetch |
从远程获取代码库 |
git pull |
下载远程代码并合并 |
git push |
上传远程代码并合并 |
文件管理
添加文件
-
使用命令
git add <file>
,注意,可反复多次使用,添加多个文件。 -
使用命令
git commit -m <message>
,完成。 -
要随时掌握工作区的状态,使用
git status
命令。 -
如果
git status
告诉你有文件被修改过,用git diff
可以查看修改内容。 -
我们同一个文件提交多次之后,可以使用
git log
查看所有提交的记录。可以使用git log --pretty=oneline
查看提交记录的hash值(版本号)。其中HEAD
表示当前版本。
版本回退
上一个版本就是HEAD^
,上上一个版本就是HEAD^^
,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100
。
# 回退到上个版本
$ git reset --hard HEAD^
此时我们由版本二回退到版本一了,我们如果想回到未来的某个版本,比如版本二,我们需要通过版本二的提交id(hash值)来操作:git reset --hard a14649e
。此时文件的内容就变成第一次提交时的内容了。
版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。
版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。
Git的版本回退速度非常快,因为Git在内部有个指向当前版本的HEAD指针,当你回退版本的时候,Git仅仅是把HEAD从指向【第二次提交】:git-head 改为指向【第一次提交】:git-head-move,然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号,你就把当前版本定位在哪。
我们可以使用git reflog
来查看每一次命令,左边的hash值就是提交的id值。
$ git reflog
a14649e (HEAD -> master) HEAD@{0}: reset: moving to a14649
203cf8e HEAD@{1}: commit: 第二次提交
a14649e (HEAD -> master) HEAD@{2}: commit (initial): 第一次提交
我们把文件往Git版本库里添加的时候,是分两步执行的:第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。
撤销修改
使用git checkout --文件名
命令git checkout -- readme.txt
意思就是,把readme.txt
文件在工作区的修改全部撤销,这里有两种情况:
一种是readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;此时工作区的文件会出现红色的警告,表示修改了文件还没有提交到暂存区。
# 查看readme.txt文件的内容
cat readme.txt
# 回到未提交到未修改的状态(此时工作区会变成绿色)
git checkout -- readme.txt
一种是readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。此时就是文件修改了并且add到暂存区。
用命令git reset HEAD <file>
可以把暂存区的修改撤销掉(unstage),重新放回工作区。
$ git reset HEAD readme.txt
总之,就是让这个文件回到最近一次git commit或git add时的状态。
删除文件
在Git中,删除也是一个修改操作,我们实战一下,先添加一个新文件test.txt到Git并且提交:
$ git add test.txt
$ git commit -m "add test.txt"
一般情况下,你通常直接在文件管理器中把没用的文件删了,或者用rm命令删了:
$ rm test.txt
这个时候,Git知道你删除了文件,因此,工作区和版本库就不一致了,git status命令会立刻告诉你哪些文件被删除了。
现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm删掉,并且git commit:
$ git rm test.txt
$ git commit -m "remove test.txt"
现在,文件就从版本库中被删除了。
小提示:先手动删除文件,然后使用git rm <file>
和git add<file>
效果是一样的。
另一种情况是删错了,因为版本库里还有呢,所以可以很轻松地把误删的文件恢复到最新版本:
$ git checkout -- test.txt
git checkout其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
分支管理
分支原理
在版本回退里,你已经知道,每次提交,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
。git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:
# 创建dev分支
$ git branch dev
# 切换到dev分支
$ git checkout dev
-
用
git branch
命令查看当前分支。此命令会列出所有分支,当前分支前面会标一个*号。 -
git merge dev
我们在master分支下操作,用于合并指定分支到当前分支。 -
删除分支:
git branch -d dev
分支冲突
当master分支和feature1分支各自都分别有新的提交,变成了这样:
这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突。使用git status会告诉我们冲突的文件,必须手动解决冲突后再提交,在冲突的文件中,Git用<<<<<<<
,=======
,>>>>>>>
标记出不同分支的内容,我们修改后保存。
用git log --graph
命令可以看到分支合并图。
分支策略
通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
git merge --no-ff -m "提交消息" dev
所以,合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。所以,团队合作的分支看起来就像这样:
Bug分支
软件开发中,bug就像家常便饭一样。有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交:
并不是你不想提交,而是工作只进行到一半,还没法提交。但是,必须在两个小时内修复该bug,怎么办?
幸好,Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作。
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复后,再git stash pop,回到工作现场。
# 存储当前的工作现场
git stash
# 查看存储的工作现场
git stash list
# 恢复指定的工作现场 恢复后,stash内容并不删除
git stash apply stash@{0}
# 删除工作现场
git stash drop
# 恢复的同时把stash内容也删了
git stash pop
Feature分支
软件开发中,总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后删除该feature分支。
此时如果feature分支还没有合并就要被删除,这时可以通过git branch -D <name>
强行删除。
Gitee
Gitee,码云。国内流行的代码托管平台,官网:https://gitee.com/。
和GitHub相比,码云也提供免费的Git仓库。此外,还集成了代码质量检测、项目演示等功能。对于团队协作开发,码云还提供了项目管理、代码托管、文档管理的服务,5人以下小团队免费。码云的免费版本也提供私有库功能,只是有5人的成员上限。
1、创建ssh key
$ ssh-keygen -t rsa -C "youremail@example.com"
你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。
为什么Gitee需要SSH Key呢?因为Gitee需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,Gitee只要知道了你的公钥,就可以确认只有你自己才能推送。
当然,Gitee允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往Gitee推送了。
- 验证添加的 key 是否生效:
ssh -T git@gitee.com
2、设置ssh公钥
登录自己的码云账号,在右上方的用户头像
下选择设置
。
3、创建项目仓库
4、克隆仓库
5、常用指令
# 克隆仓库(包括所有的分支)
git clone git@gitee.com:coydone/ssm_crud.git
# 把本地库和码云的远程库关联
git remote add origin https://gitee.com/coydone/ssm_crud.git
# 拉取远程代码库(此时会拉取主分支的代码)
git pull origin master
# 推送到gitee
git push -u origin master
IDEA中使用Gitee
1、下载Gitee的插件
2、绑定Gitee账号
3、将本地项目推送到Gitee上
4、克隆Gitee上的项目到idea中