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中