网硕互联帮助中心文章目录
- Git介绍
- Git的基本使用
-
- 工作区 暂存区 版本库
- 查看.git目录
- 版本回退
- 撤销修改
- 删除文件
- Git分支管理
-
- 分支策略
- Git远程操作
- Git标签管理
- Git多人协作
- 企业级开发模型
-
- Git分支设计规范
Git介绍
Git是最主流的版本控制器,是记录工程的每一次改动和版本迭代的一个管理系统
–Git跟踪并管理的是修改而不是文件
Git可以控制电脑上所有格式的文件
–对于文本文件，他能知道每次文件中的具体改动–比如:第8行新增了…
–对于二进制文件(比如:图片和视频)，不能知道具体改动，只能知道发生了改动
Git的基本使用
CentOS系统:
Git的安装:sudo yum -y install git
查询Git版本:git –version
Git的删除:sudo yum remove git -y
注意:rm只能删除普通文件，yum remove才能删除通过yum安装的软件
创建Git本地仓库:git init
配置Git:(这里) config后面加–global表示对该机器的所有git仓库都执行这个操作
设置用户名:git config [–global] user.name "用户名"
设置邮箱地址:git config [–global] user.email "邮箱地址"
–表示是谁提交的
查看Git配置信息：git config -l
删除配置信息eg:git config –global –unset user.name
工作区 暂存区 版本库
工作区:本地电脑上实际编辑文件的地方
暂存区:在版本库内，用来临时存放即将提交的修改
版本库:里面包含所有提交的历史版本
图中的master表示主分支 HEAD是一个指针，指向当前所在分支,然后分支指向最新提交
git add那种操作是将工作区的…文件给暂存区也搞一份(可以分开多次给)
git commit那种操作是将暂存区的…文件给版本库搞一份(可以分开多次给)
详细的指令:
添加一个或多个文件到暂存区:git add [file1] [file2] …
添加指定目录(包括他的子目录里面的东西)到暂存区:git add [dir1] [dir2] …
添加当前目录下的所有文件改动到暂存区:git add .
提交暂存区的指定文件到版本库:git commit [file1] [file2] … -m "提交说明"
提交暂存区的全部内容到版本库:git commit -m "message"
引申:
git log:查看Git日志（里面有commit ID 作者，提交日期，完整的提交说明）
–git log –pretty=oneline是查看他的简化版
git status:可以查询仓库状态
git diff [文件名]:对比工作区和暂存区的差异；没加指定文件名的话是对比的所有文件
git diff HEAD — [file]:看版本库和工作区的文件的区别
查看.git目录
里面需要注意的是:
index是暂存区
HEAD是默认指向master分支的一个指针(默认指向的是refs/heads/master)
refs/heads/master文件里面保存着当前master分支的最新commit ID
objects:是Git的数据库，每次修改和提交的文件都被压缩成对象在这(是回溯的根本)
–可以用git cat-file -p commitID来看objects对应的内容
版本回退
本质其实就是HEAD指针指向的地方变了
指令是:git reset [–soft | –mixed | –hard] [回退到哪个版本]
–soft：版本库回退到目标版本
–mixed:这个是默认选项。版本库和暂存区回退到目标版本
–hard:版本库、暂存区和工作区都回退到目标版本
回退到哪个版本:有三种表达方式
1.写commit ID(这种方式可以回到更新的版本)
2.HEAD或HEAD~0表示当前版本 HEAD^或者HEAD~1表示上一个版本 以此类推
commit ID的找法:用git reflog(比git log多很多记录)
但是，如果强制推送这种会导致新版本的记录没了
撤销修改
分三种情况考虑:
1.只在工作区进行了修改
解决方法:
a.手动撤销(不推荐)
b.用git checkout — 文件名（丢弃工作区的修改）
如果本地有新建的东西的话，还要:git clean -fd
2.在工作区和暂存区都进行了修改
解决方法:
先git reset HEAD [文件名]把暂存区撤回到工作区，再git checkout — 文件名来丢弃工作区的修改
3.在版本库、暂存区和工作区都进行了修改(但是还没push–也就是还没影响远程仓库)
解决方法：
用git reset [–soft | –mixed | –hard] [回退到哪个版本]
删除文件
步骤:
1.git rm 文件名(把他从工作区和暂存区删除)
2.git commit -m "说明"(把这个修改提交到版本库)
Git分支管理
分支的概念:
注意:分支用完之后记得删除!!!
查看当前本地所有分支:git branch(*那个分支是当前所在分支)
新建分支:git branch 新建的分支名字(刚开始指向的也是最新提交)
切换分支:git checkout 分支名
新建分支并切换到新分支:git checkout -b 分支名(如果已经存在的话会报错)
合并分支:git merge [–no-ff [-m "备注"] ] 分支名1，把分支名1合并到当前分支
可能会出现两种结果:
1.fast-forward:说明没有冲突，直接把master的指针指向分支名1最新提交的位置了
2.merge commit:有冲突并手动解决冲突后才会是这个状态
加上–no-ff表示不使用fast-forward方式
查看分支合并历史图:git log –graph –addrev-commit
–如果是fast-forward合并的话，是看不出来来源分支的
删除分支:git branch -d 分支名1(只能在其他分支下删除想要删除的分支!)
如果分支有git commit了但是还没合并的东西的话，必须git branch -D 分支名1才能删除
在合并分支时可能会出现合并冲突:
<<<<<<< HEAD
write ccc for new branch 表示这里是HEAD跟dev1冲突中HEAD的部分
=======
write bbb for new branch 表示这里是HEAD跟dev1冲突中dev1的部分
>>>>>>> dev1
解决完冲突之后需要重新git add和git commit(不用再次git merge了!)
分支策略
一般来说，开发人员日常都是在分支上进行的操作，经过一系列的测试之后才将稳定单的代码合并到master上
–因为master是用户正在使用的部分
bug分支问题:
如果在dev1上进行开发，突然master分支上面出现了bug的解决方法:
先git stash把工作区的信息先储存起来,然后切回master创建临时分支去先把bug解决了;最后就回到dev1分支用git stash pop恢复出之前的信息并删除stash内容
然后dev1开发完毕后先在dev1下跟master合并，然后再到master下合并dev1
–这样是防止merge跟dev1有冲突导致master又出bug了
引申:
git stash apply用来恢复之前的信息但是不删除stash内容
git stash drop用来删除stash内容，git stash list来查看之前储存起来的记录
Git远程操作
拿gitee举例:
新建远程仓库时:
Issue文件是用来给开发者提出有啥bug用的
Pull Request文件是给管理员提出合并申请的说明用的
每个仓库的仓库成员管理里面可以设置身份–也就是谁的权限是啥
这个对本地上传到远端是立即生效的
eg:这个如果选择c++的话，会导入针对c++的忽略规则，当然，后面可以打开.gitignore自行更改
–里面写!文件名表示忽略单个文件 eg:*.so是忽略所有.so结尾的文件
如果想被忽略的文件也能添加进暂存区的话必须强制添加才行:git add -f
注意:如果删除了文件的话git add不能同步删除操作过去的，需要git add 目录 –all
克隆远程仓库的两种方法:(如果本地本来就有这个同名仓库的话，会直接报错)
–远程仓库名的默认名称是origin
https：每次克隆或者推送时都需要输入gitee的账号密码
ssh:每次克隆或者推送时都不需要输入gitee的账号密码;但是需要现在本地生成密钥对，然后把公钥上传到Gitee
详细步骤:ssh-keygen -t rsa -C "gitee绑定的邮箱"来生成密钥对(会生成到.ssh目录里，其中id_rsa里面是私钥，id_rsa.pub是公钥)
查看远程仓库信息:git remotr
查看远程仓库的详细信息:git remote -v(fetch表示拉取记录 push表示推送记录 )
git branch:查看本地分支
git branch -r:查看远程分支
git branch -a:查看本地+远程分支
git branch -vv:查看本地分支和远程分支的绑定关系
git remote show origin:查看本地和远程仓库的完整关联关系
git remote prune origin:清除本地缓存中已经失效的远程分支
向远程仓库推送:
git push <远程仓库名> <本地分支名>:<远程分支名>
如果本地分支名跟远程分支名相同，可以简化为:git push <远程主机名><本地分支名>
注意:推送到主分支一般都是用pull request完成，而不是自己直接推送!
拉取远程仓库并跟本地合并:
git pull <远程仓库名> <本地分支名>:<远程分支名>
如果本地分支名跟远程分支名相同，可以简化为:git pull <远程主机名><本地分支名>
如果当前分支和远程分支已经建立了追踪关系的话，可以直接写git push或者git pull
引申:无追踪关系时用git pull虽然会报错，但是会执行git fetch
如何将本地分支跟远程分支建立追踪关系(追踪的作业也就是上面那条):
eg:git checkout -b dev origin/dev创建并切换到本地dev分支，并且让本地的dev追踪远程的origin/dev分支
`git branch –set-upstream-to=origin/dev dev` 把已经存在的本地`dev`分支绑定追踪到远程的`origin/dev`分支
引申:远程分支克隆到本地后是不能被直接编辑的，所以必须要搞本地分支
给命令取别名:git config –global alias.别名 原名
eg:git config –global alias.st status之后git st的效果就相当于git status了
Git标签管理
标签的作用:就是给某次commit起了一个别名(用法跟他的commit ID一样)
创建标签:
先切换到需要打标签的分支上,然后git tag 标签名 [打在哪个commit上，填那个的commit ID] 或者带注释的标签git tag -a [name] -m "说明文字" [打在哪个commit上，填那个的commit ID]
如果[]没写，就是默认打在最新提交的commit上
查看所有标签名:git tag
查看标签名1的详细信息:git show 标签名1
本地删除标签:git tag -d 标签名
删除远程仓库的标签(本地的依旧还在):git push origin : 标签名
推送添加的标签到远程仓库:git push origin 标签名 git push origin –tags(推送所有标签)
Git多人协作
这里主要演示两种场景
场景一:
两个开发者在dev分支下给master分支下的file.txt文件新增代码"a"和"b"；由开发者1新增"a"，由开发者2新增"b"
步骤:
1.开发者在本地dev分支修改代码，然后先pull远端的dev到本地，再push本地的dev到远端–这个一定要频繁操作，不要等到全写完了再搞，不然冲突会多到爆炸
–如果push本地dev到远端失败，先pull再次试图合并，合并完成就再次push
2.两边的dev都写完后，从远端拉去dev下来；切换到本地master(再pull一下)，切换到本地dev跟master合并，解决完冲突后再切换到本地master合并dev分支；最后将本地master分支推送到远端
–但是实践中，master方面的是还是用PR解决，不要自己在本地搞
场景二:
两个开发者在不同分支下给master分支新增fun1和fun2文件；开发者1新增fun1文件，开发者2新增fun2文件
步骤:开发者1创建并切换到一个分支，在分支下完成需求，然后将该分支推送到远端–之后合并给master的方法跟上面一样
–常见情景:如果开发者2生病了，需要开发者1帮忙完成后续:
先拉取远程仓库内容，如果远程仓库里面开发者2已经创建了分支，就把那个分支跟本地分支关联，然后就可以正常工作了
远程分支删除后，本地用git branch -a依然能看到那个分支的解决方法:用git remote prune origin
企业级开发模型
DevOps是一种重视软件开发人员(Dev)和IT运维技术人员(Ops)之间沟通合作的文化、运动或惯例
Git是管理代码的核心工具，是DevOps流程里代码迭代的基础
–Gitee企业版就是一个面对团队或者企业的DevOps研发管理平台
系统开发中，有几个最常用的环境:(规模大的公司还有更多的环境!)
开发环境 测试环境 生产环境(也就是正式提供对外服务的线上环境)
预发布环境:该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境
Git分支设计规范
拿Git Flow模型举例:
master是主分支(用于生产环境) release是预发布分支(用于预发布和测试环境的) develop是开发分支(用于开发环境的)
feature是需求开发分支 hotfix是紧急修复分支
eg:feature/renshen_20260318_pay
评论前必须登录！
注册