学习一手Git
引言:今天学习了一下Git工具的一些用法、来这里记录一下(写的不咋地、不要喷我😢)。Git是Linus Benedict Torvalds为帮助管理Linux内核开发的开源的版本控制软件,可以高效的处理项目版本管理的问题。熟练使用Git可以帮助我们提高协同开发的效率。
1、Git安装&配置
安装完成之后第一步,先配置自己的用户信息
$ git config --global user.name zhangsan
$ git config --global user.email email@example.com
//查看自己的配置信息,可以查看自己的user.name和user.email是否配置成功
$ git config --list
2、Git基本概念
- 工作区:放项目代码的地方。
- 存储区:保存下次将提交的文件列表信息(本地仓库与工作区的缓存)。
- 暂存区:安全存放数据的位置(有你提交的所有版本数据)。
- 远程仓库:代码最终要提交的地方(Github、Gitee等)。
3、Git上传文件和版本回退
3.1、上传过程(从工作区到远程仓库)
git status
可以查看文件的状态,下图就是temp.txt
文件处于没有被跟踪状态
git log --oneline
可查看更改的历史记录,并且一行显示一条记录,比较方便
- 首先可以在工作区中进行添加、修改、删除文件操作。
- 添加工作区的更改到暂存区
git add .
(将未被跟踪的文件添加跟踪标记、并且添加到暂存区)。 - 将暂存区的文件列表信息提交到本地仓库
git commit -m '提交信息'
。 - 跳过暂存区提交到本地仓库:
git commit -a -m '提交信息'
(提交所有已跟踪的文件、一条命令实现两个步骤)
3.2、版本回退
当我们将代码上传后感觉自己写的代码不是那么完美,那可以可以撤销我们的提交呢?当然是可以的。
git restore file
和git checkout
:恢复工作区,将暂存区的文件覆盖工作区,来丢弃本地修改git reset file
和git restore --staged
:恢复暂存区,将内容从本地仓库恢复到暂存区状态git checkout HEAD --file
:跳过暂存区,从本地仓库直接恢复到工作区(使用最后一次提交覆盖暂存区和工作区,注:没有真正跳过暂存区)git reset [回退版本]
:回退到指定的版本:将暂存区回退到指定版本(此方法回退版本后会删除之前的提交信息)
回退指定版本:git reset --hard HEAD
(一步到位、放弃工作区修改,将暂存区与本地仓库回退到上一个版本)
git reset [回退版本]
从third upload 恢复到 second upload
3.3、撤销提交
有的时候我们并不希望撤销后将之前的提交信息全部删除掉,可以使用git revert [-n] HEAD
撤销提交,生成新的提交
-n
:撤销最新的提交,但是执行后需要自己手动提交文件。
3.4、比对文件差异
git diff
—比对暂存区文件和工作区文件的差异。有的时候我们写代码写完之后准备添加到暂存区,但是想知道自己写的版本和暂存区的版本有什么差异时可以使用。
下图中提示的就是我在工作区中的readme.txt文件删除了“修改第二次”这个信息。
git diff --cached|--staged
比对暂存区和本地仓库的版本差异。
git diff [版本号] [版本号]
比对本地仓库两个版本的差异
(偷个懒不想贴图了😜😜😜)
4、Git操作远程仓库
和同事一起合作完成某个项目的时候,使用Git一起合作完成的时候将完成后的代码上传到远程仓库或者说拉取远程仓库的代码是必不可少的。下面是相关的一些操作命令(分支的概念在后面会说)。
git init
初始化本地仓库git remote add 远程仓库 url
与项目仓库建立连接git remote
查看远程仓库git remote rm 仓库名
断开远程仓库连接git pull remomte <远程分支>
拉取远程仓库的源码git push remote <本地分支>:<远程分支>
将本地仓库推送到远程仓库(这里的意思是将本地仓库选择的本地分支推送到远程仓库的选择的远程分支)git clone 远程仓库
克隆仓库到本地 (可以省略初始化本地仓库步骤)
git push
克隆下来的仓库可以该命令直接将本地仓库推送到远程仓库git pull <remote> <branch>
拉取远程仓库的数据合并到本地仓库git fetch
将数据抓取下来但是不会自动合并本地数据git merge
将抓取的数据手动合并
5、分支、冲突、储藏
5.1、分支
Git的分支我喜欢以树枝的枝条来帮助我记忆。一根枝条上面会有基于该树枝的分支
branch
,但是都有一个主干也就是master
在前面也提到过“分支”这个词,那为什么需要分支呢?或者说分支能做什么?
一般项目会有一个稳定发布的版本(master),也有正在开发的版本(develop),还有基于该项目某一个功能开发的版本,基于开发版本建立的分支(例如:Login)
如果只有一个分支的话,那么发布版本和开发版本都在一块,后续如果发布的版本出现问题后,需要修复一些问题,那么我们正在开发的版本不能提交了。这不是竹篮打水吗?
所以我们可以使用分支,在master分支上面将测试通过的代码进行发布,在develop分支上面管理我们进行开发版本的代码,在基于develop分支的功能分支上面实现某一个功能代码的管理。
分支的概念:
Git分支可以看作是一个commit对象,默认的分支是master
,会指向最新的一次提交,每一次提交信息后master也会跟着移动到最新的提交。
建立新的分支:git branch 分支名
新分支的建立一定是基于某一个分支的,默认是基于master分支来建立分支。
git branch
:查看当前分支git branch -v
:查看各分支最后一次提交对象信息git checkout <分支>
:切换到其它分支git branch -d <分支>
:删除分支git checkout -b <分支>
:新建分支且切换到新建的分支(一行命令实现两个操作)
分支合并:
新建一个test分支,test分支中完成了我们的工作,想要将test分支中的提交合并到master中:
git merge <被合并的分支>
(注意首先要从test分支切换到master分支中)
5.2、冲突
合并冲突
在工作的时候难免会遇到这样的问题。同事A把仓库拉取到本地,然后修改了temp.txt文件,准备推送到远程仓库,巧的是,同事B也拉去项目仓库,也修改了temp.txt文件,然后推送到远程仓库。这个时候就产生冲突了。如何解决这个冲突呢?
解决办法:
先
git pull
拉取远程仓库,然后根据提示打开冲突文件,手动修改,和你的提交产生冲突的同事商量怎么修改,修改后重新推送到远程仓库。
在推送前拉取一下代码,不把同事代码覆盖,好习惯+1
合并分支冲突
举个🌰,有一个master分支和一个dev分支,你正在dev分支开展新的工作,然后老板叫你去修复一下master分支里面的bug,你修复好了master里面的bug,然后提交,再回头去继续dev分支的工作,再提交时,因为再修复bug的时候把master分支的内容改掉了,master分支已经不是最初的模样了,这个时候就会产生冲突。
如何解决这个冲突呢?
可以仿照之前的合并冲突的操作,找到产生冲突的文件,然后把冲突文件中的地方修改过来。
5.3、储藏
储藏这个操作比较nice,在当前工作分支(dev)没有完成情况下,然后又不得不切换到其他分支(master)进行工作时,可以将dev分支修改暂时储藏起来,在切换到master分支去工作,等工作完了,再取出之前储藏的修改。
在切换分支之前先把当前分支修改储藏一手,好习惯+1
相关命令如下:
//储藏当前修改
git stash
//切换分支
git checkout dev
//获取储藏的修改
git stash apply
6、标签
标签的概念
前文提到的commit对象是一个会随着提交而更新的对象,那这个标签可以看作是固定的提交对象,可以用来记录下项目的版本信息 (如:v1.0.0版本)。
标签当中还可以添加一些注解的信息,非常好用。
//新建标签 -a表示该标签带注解 -m表示指定对应的标签说明
git tag -a 标签名 -m '注解信息'
//查看标签的版本信息
git show 标签名
//追加标签
git tag -a 标签名 提交id -m '注解信息'
//查看所有标签
git tag
//删除标签
git tag -d 标签名
标签推送、检出
git push 远程仓库名 标签名
将标签推送到远程仓库
git checkout -b 本地分支 标签名
通过标签检出对应的版本信息,前提是在本地分支已有该标签,若没有则使用git fetch
获取最新数据之后再检出
可以通过标签切到对应版本上进行修改,非常棒。
文末小结
记录一下自己的学习的脚步。
PS: 感觉社区大佬好多啊,大佬们写的文章感觉思路看下来思路很清晰,反观自己写之前感觉有很多东西想写下来,但是在写文章的时候还是会不知道怎么往下写。还有好多东西要学呀。
转载自:https://juejin.cn/post/7209184173302284348