Git的基础认知
-
GIT基础概念:免费开源的分布式版本控制系统。是 Linus Torvalds 为了帮助管理 Linux内核开发而开发的一个开放源码的版本控制软件。
-
作为初学者,您仅需要知道以下两点。
- Git本质:他是一个工具,您可以简单的理解为其是一个管家的形象,他的工作就是帮您打理您府上的各种事物。
- 学习Git的目的:咱们就是学习对管家的指令,只有您的指令明确,管家听得懂才会把您的府邸打理的井井有条。
定制您的专属管家(GIT)
背景:怀着一腔抱负的你来到京城,眼前的繁华景象让您大开眼界,好在您出身高贵对于这样的大场面仍能处之淡然,初来乍到,你的当务之急是什么呢?考取功名?下海经商?不不不,咱们富家大少爷一路鞍马劳顿的奔赴京城,不管之后干啥,总得先享受享受吧,望着身后装满行囊的马车您陷入了沉思,当务之急,得先找一个本地人带你熟悉熟悉环境吧,说罢您顺着人潮来到了一家气派的府邸,朱门旁一位老管家正向人们讲述他带出来的徒弟们,您心头一喜,心中暗想:正合我意。
1.Git的下载也十分简单,此处也提供了Git的链接,请放心食用。
Git的官网
2.git安装成功后仅仅需要在您进入终端命令行输入git -v 便会输出相应的版本号。
window(win+R -> cmd -> git -v)
mac (command+空格 -> Terminal -> git -v)
3.首先需要先定制一下自己管家(只需要执行一次)
//git初始化设置
git config --global user.name "Your Name" //配置您的名字
git config --global user.email "mail@example.com"//配置您的邮箱
git config --global credential store //(选配)配置启用凭证存储,第一次从远程存储库中拉取或推送时,系统会询问您用户名和密码。
参数说明
省略(Local):本地配置,只对本地仓库有效
–global: 全局配置,所有仓库生效 ♥
–system:系统配置,对所有用户生效
配置完成,查看git配置信息
git config --global --list // 查看配置信息
定制您的府邸(Repository)
背景 :经过一番操作您的专属管家已经就位,此时此刻你们主仆二人在京城的大街上四目相对一脸茫然,您的管家请示您需要他帮您打理哪一间府邸,你才意识到,您初来乍到没有府邸!!!好家伙,这不闹着玩嘛。您的管家似乎看出了您的难题,他挠了挠头给您进献了两个方案供您参考。
1.找一处合适的地方就地搭建一座府邸。
git init <project-name> //创建一个新的本地仓库 ( 省略project-name则在当前目录创建。 )
2.找一个中间商买一套您中意的府邸。
git clone <url> //克隆一个远程仓库,<url>代表远程仓库SSH链接
GIT管家的大展宏图(四个区域和四个状态)
背景:听了专属管家给您的建议,您不再茫然,寻思着自己大老远来还得自己盖房子,耗时又耗力,家财万贯的你不假思索的选了后者,中间商一看大生意上门,急忙跟您确定需求,不一会就按照您的需求,中间商就给您推荐了一座符合您标准的梦中府邸,您大手一挥这座远近闻名的府邸已经归于您名下。您带着管家走进这座大府邸,门面十分气派,步入府邸,清风拂面,繁花似锦,远观亭楼玉阁,奇山怪石,应有尽有。近看小桥流水,溪水潺潺,鸟语花香。宛如一个世外桃源。随即您就正式入住京城的府邸,将家中的一切都交予管家打理,专属管家也不负众望没几天就将您的府邸打理的井井有条,根据您的需求分为四大区域和三种状态…
文件存放的四个区域
1.工作区(working Directory):本地工作目录:我们自己操作的目录。
2.暂存区(Staging Area/Index):中间区域,用于临时存放即将提交到Git仓库的修改内容。
3.本地仓库(Local Repository):git init 命令创建的那个仓库,包含了整个项目历史和元数据,git存储代码和版本信息的主要位置。
4.远程仓库(Remote Repository):托管在远程服务器上的仓库。 常用的有GitHub、 GitLab、 Gitee。
文件的四个状态(git status)
1.未跟踪(Untrack):新创建还没有被git管理的文件状态。
2.未修改(Unmodified):已被git管理内容没有被修改的文件。
3.已修改(Modified):已经修改了的文件,但是还没有添加到暂存区中。
4.已暂存(Staged):已经修改完成之后的状态。
一张图带你清晰认知各状态之间的关系
创建Git后Git自带的一些特殊文件(简单理解为管家自带的技能,了解即可)
Git管家的常用指令系列
背景:时光飞逝,岁月如梭。天赋异禀的您当然不满足于现状,在您的运营下开启了票号买卖(银行),在天下九州都设置了属于您的分号,您自己坐镇京城稳固中央。您的金融帝国宛如一棵苍天大树扎根于这片土地,每一个分号都像苍天大树上的一条分支一般,在自己的分号中完成您分配下去的任务,为了便利您打理这庞大的金融帝国,将各地分号的存银收支账本先运往您京城的仓库中,您的专属管家GIT制定了一套规则体系用于各分号与总舵账本信息之间的交互…
1.Git常规流程(新生文件 -> 远程仓库)
1.文件存入暂存区 (git add)
git add <file> //添加目标文件到暂存区
git add *.txt //将某一类文件一同添加进暂存区例所有的.txt文件
git add . //将本地所有已跟踪的文件加入到暂存区
2.从暂存区存入本地仓库(git commit)
git commit -m [message] //将暂存区文件提交进本地仓库,message可以是一些备注信息
git log --oneline //查看简洁版提交记录
3.文件添加与提交步骤可以总结为一步
git commit -am "message" //将提交所有已修改的文件到本地仓库。
4.查看修改情况并同步远程仓库和本地仓库信息
git show //查看本地仓库做的修改
git pull //提交前的同步操作
5.提交到远程仓库
git push //提交到远程仓库
2.版本回退的四种情况
- 文件在工作区进行回退
git checkout -- filename //在工作区的文件可用此方法回退。
- 文件在暂存区进行回退
git restore --staged <file> //撤销暂存区的文件, 重新放回工作区 ( git add的反向操作)
- 文件在本地仓库进行回退
git log --oneline //查看简洁版提交记录<commit_id>
git reset --hard <commit_id> //回退到相应的版本
- 文件已经在远程仓库中
//同第三步但需要执行强推操作
git log --oneline //查看简洁版提交记录<commit_id>
git reset --hard <commit_id> //回退到相应的版本
git pull //git pull将旧版本重新上传到远程仓库,如果报错说版本低,需要强推上去 git pull -f
3.对比各区域之间的差异
- 版本上传前的比较(git commit -m 之前操作进行对比)
git diff HEAD //比较工作区和版本库之间的差异,HEAD指的是分支最新提交节点
git diff --cached //比较暂存区和版本库之间的差异
- 上传至本地仓库后生成版本号后的对比
git log --oneline //查看已提交到本地仓库的版本
git diff <版本号1> <版本号2>
//最经常用到的是比较当前版本和上一个版本之间的差异
git diff HEAD~ HEAD //(git diff HEAD~2 HEAD)代表提交之前的二个版本以此类推。
git diff HEAD^ HEAD //与~一个意思
- 文件的差异性对比
git diff + <文件名称> //用于查看某一文件的差异
4.从版本库中删除文件
方案1:
①首先使用 rm <file1.txt>在本地工作区中删除目标文件
②查看仓库状态 git status (会提示更新暂存区中的文件)
③git ls-files 查看暂存区中的文件 (正常会看到暂存区中的内容没有被删除)
④git add .(更新暂存区中的文件)
再提交git commit -m “提交格式”
方案2:(rm 命令是会删除本地的工作区和暂存区的文件)
① git rm file2.txt
② git status 查看仓库状态 (该文件也被删除)
③ git ls-files 查看暂存区中的文件
再提交git commit -m “提交格式”
Git分支相关知识的总结
背景:书接上文,话说各地分号的仓库堆积着各种各样的物资,而您生性放浪不羁,不愿花过多时间和经历去管理这庞大的商业金融帝国,将一切繁杂的经营管理统统交付予您的专属管家,随着时间的推移,您的买卖越来越大,仅仅靠您的专属管家已经不足以替您管理好这巨额的产业,聪明的你没多久就想了个好办法,在天下九州设置不同的分舵,每一个分舵设置一名专属管家,每个管家管理此地最大的产业仓库称为本地仓库,他们可以根据自己的需求设置不同的分舵或合并分舵或撤销分舵用于丰富他们的本地仓库的物资,他们处理相关事务就需要前往该问题所在的分舵,他们听命于您,您一声令下,这些本地仓库可以将其中的物资统统转运到京城的远程仓库中,朝发夕至速度极快,有了这样的好办法,您手下的产业越来越多,闲不住的您决定巡游天下九州…
git中的分支Branch
1.查看当前您所在仓库中的分支
git branch //查看当前您所在的仓库中所有分支
2.创建一个新的分支
git branch <branch_name> //创建一个新的分支(分舵)
git checkout -b <branch-name> //切换到指定分支, 并切换到新分支
3.切换分支两种办法
//两种切换方法,区别在于避免checkout有歧义,故专门使用该指令切换分支
git checkout <branch_name> //切换到目标分支
git switch <branch_name> //切换到目标分支
4.合并分支的两种方法
//将不同分支合并到当前分支中,merge后面的分支名是将要被合并的分支。
//例如我们需要把dev合并到main分支上时,首先先切入main分支后再执行git merge dev操作达到目的。
git merge <branch_name> //将<branch_name>分支合并到您当前所在的分支上
git rebase <branch-name> //在任意分支上执行变基操作将两分支合并到一起
git log --graph --oneline --decorate --all //查看合并分支图
知识补充:
//查看图形化页面的提交记录原本命令
git log --graph --oneline --decorate --all
//命令别名化
alias graph="git log --oneline --graph --decorate --all"
//之后两者就是等价状态
graph
4.1两种合并方式的区别和遇到的问题
- merge合并
①合并成功后原分支依旧存在,为了避免分支过多冗余可以删除相应分支
git branch -d <branch_name> // 如果合并后一个分支不需要了,就可以使用该命令删除它
git branch -D <branch_name> //如果一个分支还是没有合并就不要了,就需要用-D强制删除
②该方法合并可能会出现合并冲突的情况需进行手动合并或终止合并
//手动合并合并完成再进行提交到本地仓库
git diff / git status //进行对比操作查看冲突文件,进行手动修改
git commit -am "name" //name为提交备注
//终止合并
git merge --about //终止合并
- rebase(变基)合并
变基合并的解释:如下图最初合并前为中间状态。如果在dev分支上执行rebase操作,首先找到dev分支和main分支的共同祖先main3,找到main分支上的最新提交记录main5,将dev分支整个嫁接到main分支的后面,合并成一条分支。
记忆技巧:在哪个分支上变基操作,该分支变基后在总主分支的上面。
4.2 merge和rebase 合并优缺点分析
- merge
优点:不会破坏原分支的提交历史,方便回溯和查看。
缺点:会产生额外的提交节点,分支图比较复杂。 - Rebase(不要在公共的分支进行rebase操作)
优点:不会新增额外的提交记录,形成线性历史,比较直观和干净。
缺点:会改变提交历史,改变了当前分支branch out 的节点,避免在共享分支使用。
5.git stash
使用场景:在一个分支开发新功能,还没开发完毕,做到一半时有反馈紧急bug需要处理,但是新功能开发了一半又不想提交。
Stash操作可以把当前工作现场 “储藏”起来, 等以后恢复现场后继续工作。
1.分支有改变时不提交又不能切换分支
0.将此时此刻的状态存储起来
git stash save "message" //massage是您存储写的信息,方便二次打开
//-u 参数表示把所有未跟踪的文件也一并存储;
//-a 参数表示把所有未跟踪的文件和忽略的文件也一并存储;
//save参数表示存储的信息, 可以不写。
解决方法:
①查看本地储藏列表有几条,按照需求进行恢复
git stash list //查看所有stash
git stash pop //恢复最近的一次stash
②看list列表看是否有需要删除的版本
git stash drop --n //n指代是您删除{n}的序列号
git stash clear //删除所有的stash
③根据需要可以恢复到指定的版本
git stash pop stash@{n} //n为指定的版本,stash@{2}表示第三个stash, stash@{0}表示最近的stash。
//推荐apply
git stash apply n //n指代是您删除{n}的序列号
//pop和apply的区别是, pop会把stash内容删除, 而apply不会。
可以使用git stash drop 来删除stash。
Branch管理和工作流程模型(了解)
GitFlow 模型
GitFlow模型:将分支分成了五种类型
主要分支和辅助分支
主要分支(长期存在的):主分支+开发分支
辅助分支(完成各自功能后删除掉):hotfit+功能分支+release
git tag 来规定版本号
git tag <tag-name> //给当前的提交打上标签, 通常用于版本发布。
GitHubFlow 模型(系统化企业常用)
①团队成员通过从主分支上分离出自己的分支进行开发和测试。
②团队成员可以在本地分支提交代码add/commits.
③开发完成后 再进行pull request操作进行(PR 合并请求),团队成员可以对其进行评审(discuss and review commits)-> deploy
④分支的命名规范和分支的创建规范,分支的合并规范
远程仓库相关知识的总结
背景:君曾记否,您初入京城耗费重金所买的大府邸,恍惚间数年间已经变成您商业金融帝国的总舵啦,其占地之广足有数千顷,堂内亭宇楼阁数不胜数,经过您专属管家的打理,几年下来您府院经常扩建,随着天下九州分舵的建立,您的府邸已经成为总舵啦,在各个分舵的努力下,您早已经日入千金,对于各地的分舵仓库而言,您府邸仓库比他们更为奢华,是远近闻名的远程仓库,其中的物资应有尽有,各地分舵的分舵主自然要过一段时间将其本地仓库的物资跟您进贡,此时的您已富甲一方,可是京城有名的大人物,然事务繁忙,您生性自由,为了摆脱这繁琐的杂事九州进贡的麻烦事,您赋予了他们更多的权力,他们可以根据自己的需求添查删改您府邸的远程仓库,同时他们也能够定期将相应的物资推送到您的府邸,人生一世,辉煌莫过于此…
本地仓库与远程仓库之间的交互
① 添加远程仓库
git remote add <remote-name> <remote-url> //添加远程仓库
②查看远程仓库
git remote -v //查看远程仓库
③删除远程仓库
git remote rm <remote-name> //删除远程仓库
④重命名远程仓库
git remote rename <old-name> <new-name> //重命名远程仓库。
⑤从远程仓库拉去代码
git pull //默认拉去代码
git pull <remote-name> <branch-name> //从远程仓库拉取代码。 默认拉取远程仓库名origin的master或者main分支。
⑥推送代码到远程仓库中
git push //推送代码进入远程仓库
⑦获取所有的远程分支
git fetch <remote-name> //获取所有的远程分支
⑧查看所有的远程分支
git branch -r //查看远程分支
文章总结:
背景:正当您想着您商业帝国该如何进一步发展,自己家财万贯该如何进一步去扩大经营时,天空一声炸雷将你惊醒坐起,什么琼楼玉宇,小桥流水,鸟语花香,家产万贯,便是黄粱一梦罢了…
文章的由来
本篇文章是小生通过自己的学习总结以及步入社会后工作之后和网络看的一些优秀课程总结而来,大家如果时间充裕可以在GIT课程进行相应的学习,该课程十分详细,我是十分推荐的!
创作初衷
感谢大家的阅读,我也是突然心血来潮,想把自己学习git之后得到的收获跟大家做一个分享,一方面我自己做一个笔记加深记忆,另一方面是CSDN给予我学习和生活很大的帮助,希望我的文章能得到大家的喜欢,对了,如果您看完之后有什么需要补充或者修改的,请在评论区告诉我哈,还望不吝赐教。共同进步!