Git学习和使用指南详细篇

发布于:2024-05-24 ⋅ 阅读:(51) ⋅ 点赞:(0)

天行健,君子以自强不息;地势坤,君子以厚德载物。


每个人都有惰性,但不断学习是好好生活的根本,共勉!


文章均为学习整理笔记,分享记录为主,如有错误请指正,共同学习进步。

文章目录


Git相关文章参考:
Git学习和使用指南简单篇
Git命令汇总

一、Git介绍

常见的版本控制系统有:本地版本控制系统、集中式版本控制系统、分布式版本控制系统

1. 本地版本控制系统

复制整个项目目录作为版本控制文件
流行的本地版本控制系统如RCS
在硬盘上保存补丁集,每个补丁记录一个版本的变动

2. 集中式版本控制系统

英文Centalized Version Control System,简称CVCS,使用一个集中管理的服务器保存版本控制文件
优点是每个人都能看到别人做了什么修改
缺点是服务器一旦宕机就无法提交更新,若服务器磁盘未做备份,一旦损坏无法恢复
主流的集中式版本控制系统如:CVS、Subversion、Perforce

3. 分布式版本控制系统

Distributed Version Control System,简称DVCS,代码仓库和记录都会被镜像到本地,也就是服务器和本地都有备份项目代码和历史记录
优点是速度更快,协作更方便
主流的集中式版本控制系统如:Git、Mercurial、Bazaar、Darcs

二、Git配置

.gitignore文件中的语法:
#表示注释
*.class表示排除所有.class文件
!.class表示不排除.class文件
app.class表示排除app.class文件
!app.class表示不排除app.class文件

Git命令

1. Git配置工具config的介绍

git的外观和行为配置都使用git config工具来控制
外观和行为配置的变量存储在三个位置:/etc/gitconfig~/.gitconfig或者~/.config/git/config.git/config

1.1 /etc/gitconfig文件

存放系统上每一个用户及用户的仓库的通用配置
执行git config命令时带上–system选项就会读写该文件中的配置变量,但需要系统管理员权限

1.2 ~/.gitconfig或者~/.config/git/config文件:

该文件只配置用户参数,可通过–global选项让git强制读写该文件,会对系统所有仓库项目生效

1.3 当前仓库的Git目录中的config文件(.git/config

当前仓库的Git目录中的config文件(.git/config)
对当前仓库生效,进入某个git仓库后,默认情况下就会使用该文件,但可通过–local选项让git强制读写该文件

2. 查看Git的配置信息

2.1 查看Git配置文件及文件位置

查看配置文件及所在位置的命令

git config --list --show-origin

注意:
.git/config的配置会覆盖/etc/config的配置
在windows中查看配置文件和位置时,git会查找C:\Users$USER的.gitconfig文件
这里$USER是变量,对应的是你自己电脑的用户名

2.2 查看Git配置参数列表

查看Git配置参数列表,如账号名邮箱等的参数内容

git config --list

3. 配置Git的用户信息

3.1 全局配置用户信息

在机器的整个环境下所有项目都会使用这个用户信息提交代码
用户名配置,寒山是我自定义的用户名

git config --global user.name "寒山"

邮箱配置,hanshan@163.com是我自己的邮箱(假的,这名字被人取了)

git config --global user.email hanshan@163.com

3.2 特定项目配置用户信息

在某个项目下想使用单独的用户信息提交代码,可使用不带–global的命令配置用户信息
某个项目目录下配置用户名

git config user.name "hanshan"

某个项目目录下配置用户邮箱

git config user.email hanshan@163.com

3.3 查看Git单一参数

查看用户名

git config user.name

查看邮箱

git config user.email

等等

4. 配置Git界面颜色

git config --global color.ui true

5. 配置Git忽略文件

在提交时想忽略一些文件不提交,如密码等配置文件,可使用.gitignore文件配置
在git工作区的根目录即.git文件同级目录,创建.gitignore文件(正常在使用远程仓库时会自动生成)
在.gitignore文件中编写需要忽略的文件即可

忽略具体某个文件则只需在.gitignore文件中写该文件名即可
忽略某一类型的文件可使用*.类型的方式,如忽略.class结尾的文件可写成*.class

还有一种情况就是忽略某一类型文件后其中有一个文件不想忽略,则可将该文件卸载忽略文件中并加上!,如忽略.class结尾文件后不想忽略java.class文件,可以在.gitignore中写!java.class

忽略文件.gitignore语法

5.1 .*

.*表示忽略所有以.开头的文件

5.2 *.class

*.class表示忽略所有以.class结尾的文件

5.3 a.class

a.class表示忽略文件a.class

5.4 !.*

!.*表示不排除以.开头的文件

5.5 !*.class

!*.class表示不排除所有以.class结尾的文件

注意:
如果想强制添加被忽略的文件,执行时加-f参数强制执行即可

git add -f a.class				

检查忽略规则

git check-ignore

6. 配置Git命令别名

当使用git命令时,可以通过配置git命令别名来简写git命令
如git add .可换成git a .
git commit -am"" 可以换成git cm -am""
git pull 可以换成git pl
git push 可以换成git ps

6.1 配置方式

--global是配置全局,不加则只对当前用户
语法如下

git config --global alais.gitNewCommands 'git-origin-commands'

gitNewCommands表示新命令即别名
git-origin-commands表示原命令

6.2 举例

git config --global alais.a add
git config  --global alais.cm commit

当然除了单词的缩写,还可以将组合命令简写
如显示最后一次提交信息

git log -1
git config --global alais.last 'log -1'

后续即可使用git last相当于git log -1

6.3 删除别名

如何将配置的别名删除
全局配置文件的删除方法:
在.git/config文件中的alais部分是别名的配置参数,删除对应的别名即可
用户配置文件的删除方法:
当前用户的配置文件放在用户目录下的.gitconfig中,删除文件中对应的别名即可

三、Git使用

1. 克隆clone

1.1 介绍

克隆现有仓库使用命令git clone
克隆项目无需先初始化仓库,直接通过项目仓库的远程地址克隆即可将项目拉取下来,并在本地创建仓库,且克隆下来的仓库的默认主分支就是远程仓库设定的默认主分支

远程仓库地址https和ssh比较常用,但一般克隆使用https无需配置sshkey,公有仓库可直接克隆下来,私有仓库可通过账号密码验证后克隆下来

1.2 clone命令

先在远程仓库中复制仓库地址
然后使用克隆命令将项目克隆到本地,命令如下

git clone https://dddd/ddd/ddd/test

执行后会在当前目录位置创建一个名为test的目录,test目录下会有一个.git文件夹

1.3 自定义克隆项目本地名称

远程项目名称克隆下来后在本地的文件夹名称如果想在克隆时就修改,可通过命令后加文件夹名称指定,如

git clone https://dddd/ddd/ddd/test pro01

执行后远程项目名在克隆到本地后就会变成pro01

2. 初始化版本库init

在本地文件夹中创建版本库使用init命令

git init

执行后可在当前目录中生成一个.git文件夹,该文件夹就是版本仓库,但它是隐藏文件,如果未设置显示隐藏文件可用命令查看

2.1 查看隐藏文件

查看隐藏文件可在当前目录打开cmd窗口输入

ls -ah

2.2 指定分支初始化

在初始化时默认的主分支是master(如果在安装git时没有修改的话),可通过-b指定初始化时默认的主分支名称,如将默认分支指定为main

git init -b main

3. 添加文件到版本库add

将本地文件添加到版本库使用git add命令如下

3.1 添加所有文件

注意最后的一个点,表示全部

git add .

3.2 添加某个文件

直接填写文件全名即可,如添加test01.text到版本库

git add test01.text

3.3 添加某些文件

将所需添加的文件罗列出来即可,如添加test01.text、tee.class、dd.py三个文件到版本库

git add test01.text tee.class dd.py

4. 提交到版本库commit

将本地文件提交到版本库中

git commit -m "提交时的描述信息"

5. 添加add和提交commit的区别

既然都是将本地文件放到仓库中,他俩有啥区别,为啥要先add再commit
看一下工作区、版本库和暂存区的描述应该就知道了

  • 工作区就是本地文件目录
  • 版本库就是本地的.git文件夹
  • 当工作区的文件通过add添加到版本库,实际上是提交到了版本库中的暂存区
  • 当文件通过commit提交后,实际上是将版本库中的暂存区里所有文件提交到了当前分支上

在这里插入图片描述

6. 查看仓库状态

6.1 查看git仓库当前状态变化

git status

6.2 具体变化查看命令

git diff

6.3 status和diff的区别

git status只能查看到那些文件改动了,但看不到具体改动的内容
git diff可以看到文件内容改动情况

7. 日志查看

git log
git log --pretty=online

8. 回退

git回退到上一个版本的命令
git中用HEAD表示当前版本,HEAD^表示上一个版本,HEAD^^表示上上一个版本
上一百个版本使用HEAD~100表示
回退上一个版本的命令

git reset --hard HEAD^

9. 重置

当回退后想要恢复到最新版本,使用git reset --hard 新版本的commitId
如何查看最新版本的commit id,使用命令

git reflog

找到对应的commitId,然后使用

git reset --hard commitId

进行重置

四、Git版本管理

1. 撤销修改

当你提交一次代码到当前分支时,注释信息写错了或者之前add的时候少添加了某个文件,此时想重新操作后再commit,但是第二次commit就会留下一个commit的历史,我不想要这个commit历史
此时就可以用该命令

git commit --amend

执行后不会有上一次commit的描述信息也不会有上次commit的历史,只会看到后面这次的commit信息

2. 取消暂存的文件

当使用add添加文件到暂存区后,发现这个文件并不需要提交,此时想要取消暂存

git reset HEAD file

file为所要取消暂存的文件,
举例
如取消暂存区文件test01.text

git reset HEAD test01.text

3. 撤销对文件的修改

当你对某个文件做了修改,但是原来的更好,你想恢复,则可用以下命令撤销修改

git checkout --file

使用--指定文件名,可对该文件的修改进行撤销
对文件的修改撤销之后该文件在本地的所有修改都会消失,无法恢复
git会使用最近提交的版本覆盖掉

4. 删除文件

4.1 删除本地文件

本地文件夹删除文件的方式可以是直接右键删除文件,也可以使用rm命令删除文件
删除文件命令

rm test.txt

4.2 删除暂存区文件

当工作区的文件也就是本地文件夹的文件删除时,如果该文件之前提交到了暂存区,git版本库的暂存区也会知道,此时使用以下命令删除暂存区对应的文件

git rm 文件

然后

git commit -m"rm file"

5. 恢复删除的文件

如果删除错了如何恢复

git checkout --file

使用上述命令恢复对文件的删除,如删了test01.text想要恢复

git checkout --test01.text

注意:使用该恢复命令的前提是该文件之前提交到版本库过,如果从未提交过则无法使用该命令恢复

6. 总结

  • 修改了工作区文件想要撤销该文件的修改使用git checkout --file
  • 修改了工作区文件后并将该文件添加到了暂存区,此时想撤销该文件的修改需要先将该文件从暂存区移除使用命令git reset HEAD file然后再使用git checkout --file撤销修改
  • 修改了工作区文件并添加到暂存区然后又提交到了分支上但并未使用push推送到远程仓库时,此时想撤销文件操作需要使用git reset --hard commitId回到上一个提交

五、Git分支的查、增、切、合、删

1. 查看分支

git branch

带*的是当前分支

2. 创建分支

git branch 分支名

3. 切换分支

git checkout 分支名

4. 创建分支并切换到新建分支(如新建dev)

git checkout -b dev

5. 合并分支

5.1 合并命令

git merge 分支名

该命令表示将命令中的分支内容合并到当前分支
如在dev分支提交了内容,想要合并到master分支,需要先将当前分支位置从dev切换到master,使用命令

git checkout master

然后再使用merge命令将dev合并到当前的master分支,命令为

git merge dev

5.2 合并策略

5.2.1 fast forward

正常git merge合并分支时使用的是默认的fast forward模式
该模式合并后删除分支会丢失分支信息

5.2.2 no ff

在git merge时添加–no-ff参数禁用fast forward模式,这样在删除分支后,分支信息会保留
删除分支后查看分支历史的命令:

git log --graph --pretty=online --abbrev-commit

6. 删除分支

git branch -d 分支名

该命令表示删除指定分支

强制删除,谨慎使用

git branch -D 分支名

7. 切换分支switch

为了区分切换分支和撤销修改的命令git checkout <branch>git checkout --<file>
在新版本的git中使用switch来实现切换分支

7.1 切换并创建分支

git switch 分支名

7.2 切换到某个分支

git switch -c 分支名

8. 查看分支历史

git log --graph --pretty=online --abbrev-commit

六、分支使用策略

通常情况下master分支不被多人使用,只用来最终上线前的提交,大多数情况下使用dev分支进行开发提交
而项目组开发成员有多个时,可在dev分支下继续创建多个分支进行不同人员的开发提交,每个人都提交到dev,在上线前将dev提交到master即可
分支名:
除了主分支master、开发分支dev之外常见的还有bug分支和feature分支

七、Git分支之Bug分支

1. 保护现场stash

bug分支:
当有一个bug需要修复,我们可以新建一个bug分支进行bug处理,处理结束后提交然后删除此bug分支即可
保护现场:
但当现有的开发分支dev分支上的任务还没有完成暂时不能提交,这时直接创建bug分支提交,会失败,因为bug分支是基于dev分支创建的,此时该如何创建bug分支,有一种方式:
使用保护现场的命令将现有分支dev此时的状态保存下来
先查看已提交和未提交的内容

git status

再将当前分支的状态保存下来

git stash

然后再查看发现暂存区没有未提交的内容了

git status

将状态保存后,可以开始bug修复了

2. 修复Bug

修复步骤:

2.1 切换分支

从哪个分支修复bug,就切换到那个分支上,如果我们需要再master上修复,则先切换到master

git checkout master

2.2 创建并切换到bug分支

在master分支创建bug分支,如b-001

git checkout -b b-001

2.3 修复、提交

修复后add,如修复了test01.text文件

git add test01.text

然后commit

git commit -m "fix test01.text"

切换回master分支

git switch master

将b-001的修改合并到master

git merge --no-ff -m "merge message for bug b-001"

现在再切换回dev分支

git switch dev

此时之前保存的dev状态还没有还原,现在的暂存区依旧是空的,如何恢复,执行以下命令

3. 恢复现场

恢复现场:

3.1 查看现场列表

先查看保护的现场列表

git stash list

查看的结果中有一个stash的id如stash@{0},id后面会有对应的描述包含了分支的commitId

3.2 根据stashId恢复现场

根据stash的id恢复:

git stash apply stashId

3.3 删除现场

恢复后需要删除stash,因为不会自动删除

git stash drop stashId

3.4 恢复并删除现场

也可以使用pop直接恢复同时删除,也就是相当于执行了上面的两个命令(3.2和3.3)

git stash pop stashId

4. 修复操作的同步

bug修复操作的同步:
Git有复制特定提交到当前分支的命令cherry-pick
在master分支修复了bug之后如何同步到dev分支,毕竟master分支的bug,dev也会有,此时可以通过将bug的提交复制到dev即可
b-001的bug修复在master分支的提交Id为10010,我们将该提交复制到当前的dev分支即可
确认当前分支是dev,查看当前分支,带*好的是当前分支

git branch

复制bug修复的提交到当前分支

git cherry-pick 10010

执行该命令后git会将此次执行的操作也当做一次commit提交,并生成一个commitId

八、Git分支之Feature分支

feature分支:
用于各种新功能开发时创建的临时分支,类似于bug分支,开发完合并后即删除
删除分支:

git branch -d 分支名

注意:当创建分支后,未提交到其他分支就直接删除该分支,则会删除失败
此时如何解决,使用大写的D参数进行强制删除

git branch -D 分支名

九、解决冲突

冲突解决:
master分支文件a的内容为1+1
dev分支的文件a的内容为1-1

1. 合并merge

此时先在master分支提交,然后再切换到dev分支提交,然后使用mrege命令合并

git merge

此时就会报文件冲突无法合并需手动解决后再进行合并,报错内容会显示具体哪个文件冲突

2. 查看冲突

先查看冲突内容

git status

此命令也可查看到冲突文件是哪个

3. 解决冲突

查看冲突并手动修改解决
解决后再次合并即可

十、转移命令cherry-pick

git cherry-pick的使用:

1. 转移单个提交

1.1 转移某分支最新提交到当前分支

以下命令会将分支名对应的最新提交放到当前分支

git cherry-pick 分支名

举例:
如将dev的最新提交a转移到master分支
切换当前分支到master

git checkout master

将a转移到master

git cherry-pick dev

1.2 转移某分支的一个提交到当前分支

将一个分支的提交转移到另一个分支
正常我们将一个分支的内容全部转移到另一个分支时直接使用git merge命令合并即可
当我们只需要将分支的某个提交改动转移到另一个分支时,就可以用git cherry-pick
语法:

git cherry-pick commitId

commitId为提交的Id
举例:
dev的提交有:a-b-c
master的提交有:d-e-f

现在将master的提交e放到dev分支:
先将当前分支切换到dev

git switch dev

然后将提交e放到dev分支

git cherry-pick e

此时dev的分支如下a-b-c-e

2. 转移多个提交

2.1 转移多个提交

一次转移多个提交,可在命令后跟提交Id,可列举多个

git cherry-pick 提交a 提交b

此时会在当前分支应用这两个分支,并会生成两个对应的新提交

2.2 转移某分支的连续提交

如dev的提交有a-b-c-d-e-f-g-h-i
现在将dev分支的d.e.f.g分支都转移到master分支

git cherry-pick c..g

只能c…g不可以g…c,要遵循先后顺序
上面命令用法转移的提交不包含c,如果像包含c如下

git cherry-pick c^..g

该命令会将cdefg转移到分支

3. 配置项

cherry-pick常用配置如下:

参数 含义
-e--edit 表示打开外部编辑器,编辑提交信息
-n--no-commit 表示只更新工作区和暂存区且不产生新的提交
-x 表示在提交信息的末尾追加一行cherry picked from commit…方便以后查到这个提交如何产生的
-s--signoff 表示在提交信息的末尾追加一行操作者的签名,方便查看谁操作的
-m parent-number--mainline parent-number 表示如果原始提交是一个合并节点,来自于两个分支的合并,则cherry pick默认将失败,因为不知道采用哪个分支的代码变动

注意:
-m参数配置项是告诉git应该采用哪个分支的变动,参数parent-number是从1开始的整数,表示原始提交的父分支编号
git cherry-pick -m 1 <commitHash>表示cherry-pick采用提交commitHash来自编号1的父分支的变动,正常来说1号父分支是接受变动的分支,2号父分支是座位变动来源的分支

4. 解决代码冲突

当执行cherry-pick命令是遇到代码冲突,cherry pick会停下
以下为三种情况,可根据需要选用

4.1 如何解决并继续

先将冲突代码手动解决,然后
第一步,将修改的文件重新加入暂存区

git add 修改的文件

第二步,继续执行cherry-pick

git cherry-pick --continue

4.2 如何放弃合并将文件恢复到操作前

git cherry-pick --abort

4.3 退出cherry-pick但不回到操作前

git cherry-pick --quit

5. 转移到另一个代码库

git cherry-pick不仅可以在同一个代码库中操作,还可以将提交转移到另一个代码库

现将另一个代码库添加为远程仓库,如添加远程仓库target

git remote add target 远程仓库地址

将远程仓库抓取到本地

git fetch target

检查从远程仓库转移的提交,获取哈希值

git log target/master

转移提交

git cherry-pick <commitHash>

十一、Git多人协作

git 本地仓库与远程仓库建立连接时是将本地的master分支和远程的master分支对应
远程仓库的默认名称为origin

1. 查看远程仓库

查看远程仓库名

git remote

查看远程仓库详细信息

git remote -v

该命令可查看到抓取fetch和推送push的地址,若无推送权限则不会显示push地址

2. 推送代码

把当前分支本地提交的代码推送到远程仓库,推送时需要指定本地分支,git将该分支推送到远程仓库对应的远程分支上
推送语法:

git push origin <branch>

举例:
将本地master分支的提交推送的对应的远程仓库的master分支

git push origin master

将本地dev分支的提交推送到对应远程仓库的dev分支

git push origin dev

注意:
master分支为主分支,时刻需与远程同步,故需推送
dev分支为开发,团队成员都需要使用,故需推送
bug分支只用于本地修复bug,无需推送
feature分支需不需要推送取决于是否合作开发

3. 拉取分支

当多人协同工作时,不同人提交的代码不同,代码需要合并,此时推送代码可能会失败,需要解决冲突后提交
当前分支为master,先切换到dev,并将dev与远程的dev连接

git checkout -b dev origin/dev

在dev分支上修改代码,然后添加、提交并推送到远程仓库

git add .
git commit -am "描述信息"
git push origin dev

如果其他人也提交了你修改的那个文件,并且文件内容做了和你不同的修改,则可能会冲突,推送失败
此时需要先拉取最新的代码

git pull

若拉取失败,原因根据提示可能是本地dev未指定远程origin/dev,直接设置本地与远程dev的连接

git branch --set-upstream-to=origin/dev dev

建立链接后再拉取

git pull

拉取成功,解决冲突然后提交再推送

git commit -am ""
git push origin dev

总结多人协作的代码拉取:

  • git push origin <branch-name>推送代码
  • 失败则git pull拉取最新代码到本地
  • 有冲突则解决冲突后并提交git commit
  • 然后推送git push origin <branch-name>

注意:
git pull提示no tracking information表示本地与远程分支未建立链接
用命令建立连接git branch --set-upstream-to <branch-name> origin/<branch-name>

4. rebase

rebase操作可以把本地未push的分叉提交历史整理成直线
rebase的目的是让查看历史提交的变化看起来更简单
缺点:本地的分叉提交会被修改

十三、Git标签使用

标签tag也是版本库的一个快照,在发布一个版本时可以打一个标签,确定该版本对应的打标签的时刻,未来可用该标签找到对应的版本进行恢复
标签实质上是指向某个commit的指针,但不可移动
tag和commit绑定在一起,更容易根据tag的内容(一般为版本号)找到对应的commit版本

1. 查看所有标签

查看所有标签名,该命令列出的标签列表不是按照时间顺序,而是根据字母书序排列

git tag

通过show查看指定标签

git show <tag-name>

如果查看标签v1.0的标签内容

git show v1.0

2.对当前提交打标签

默认情况下标签会打在最新提交的commit上
打标签

git tag <tag-name>

如创建标签v1.0

git tag v1.0

3. 对历史提交打标签

默认情况下标签会打在最新提交的commit上
如果忘记打标签,但时间已经过了,如何对以前的commit打标签?
指定commitid打标签

3.1 查看提交历史

查看提交历史,找到想要打标签的commitId

git log --pretty=online --abbrev-commit

3.2 根据commitId打标签

对指定的commitId打标签

git tag <tag-name> commitId

4. 创建带有说明的标签

-a参数指定标签名,-m参数指定描述文字
命令如下

git tag -a <tag-name> -m "tag-message"

git tag -a v1.0 -m "version 1.0 for test released"

使用git show <tag-name>查看标签内容包括描述信息
如果标签对应的commit既出现在master分支又出现在dev分支,则两个分支上都可以看到该标签

5. 删除标签

语法

git tag -d <tag-name>

git tag -d v1.0

6. 推送标签到远程

创建的标签只存在本地,不自动推送到远程,所以打错标签可本地安全删除

6.1 推送指定标签到远程

如需将标签推送到远程,则可用以下命令

git push origin <tag-name>

6.2 推送所有标签到远程

也可以一次性将所有标签全部推送到远程

git push origin --tags

7. 删除标签

若标签已推送到远程,现在想删除该标签,需要先从本地删除再从远程删除

7.1 本地删除

git tag -d <tag-name>

7.2 远程删除

git push origin :refs/tags/<tag-name>

8. 总结

推送一个本地标签到远程

git push origin <tag-name>

推送全部标签到远程

git push origin --tags

删除一个本地标签

git tag -d <tag-name>

删除一个远程标签

git push origin :refs/tags/<tag-name>

创建一个带描述的标签

git tag -a <tag-name> -m "messages"

创建一个带gpg签名的标签

git tag -s <tag-name> -m "messages"

十四、Git命令汇总

由于命令太多,这里不进行罗列,请参考文章:Git命令汇总


感谢阅读,祝君暴富!


网站公告

今日签到

点亮在社区的每一天
去签到