侧边栏壁纸
博主头像
coydone博主等级

记录学习，分享生活的个人站点

  • 累计撰写 306 篇文章
  • 累计创建 51 个标签
  • 累计收到 0 条评论
标签搜索

目 录CONTENT

文章目录
Java框架

Git

coydone
coydone
2022-03-02 / 0 评论 / 0 点赞 / 420 阅读 / 7,208 字 / 正在检测是否收录...
温馨提示：
本文最后更新于 2022-05-02，若内容或图片失效，请留言反馈。部分素材来自网络，若不小心影响到您的利益，请联系我们删除。

Git大纲

Git概述

项目的版本管理

在项目开发过程中，项目每开发到一个节点就会对当前项目进行备份，这个备份就是项目的一个版本；当我们继续开发一个阶段后，再次进行备份，就生成新的版本。多个版本的集合就是项目的版本库。

在项目版本管理中，我们可以使用手动进行管理，但是存在一些问题：

需要手动维护版本的更新日志，记录每个版本的变化。

需要手动查找历史版本，当历史版本比较多的时候，查找工作很繁琐，当我们需要回退到某个版本时，只能够手动的通过IDE工具手动打开。

版本管理工具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

Git-2.24.0.2版本：Git-2.24.0.2-64-bit.exe

Git-2.33.1版本：Git-2.33.1-64-bit.exe

测试安装完成：cmd中输入 git --version 。

工作流程

一般的工作流程为：

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的基本架构：

创建仓库命令

命令 说明
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表示当前版本。

git log --online：每个版本以一行显示。

版本回退

上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

# 回退到上个版本
$ git reset --hard HEAD^

此时我们由版本二回退到版本一了，我们如果想回到未来的某个版本，比如版本二，我们需要通过版本二的提交id（hash值）来操作：git reset --hard a14649e。此时文件的内容就变成第一次提交时的内容了。

版本号没必要写全，前几位就可以了，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 branch branch_name #创建分支
git checkout branch_name #切换分支
git checkout 版本号-b branch_name #检出分支
git merge 分支名称 #合并分支 （将指定的分支合并到当前分支）
git log --online --graph  #查看分支及版本视图

用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中

创建本地版本库，会生成.git文件夹。

IDEA中设置忽略配置文件：在项目根目录下创建.gitignore 文件。

.idea
target
*.iml
0
Git 项目工具
  1. qrcode alipay
  2. qrcode weixin
版权归属： coydone
本文链接： https://www.coydone.com/archives/187
许可协议： 本文使用《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》协议授权

评论区