Git的常见用法

1.git init 初始化git生成git仓库

生成.git文件记录所有变更行为

2.git add <filename> 添文件到暂存区

git add .加入所有文件到暂存区

3.git commit -m ‘message’提交文件到本地仓库

git commit规范:

1
2
3
4
5
6
7
8
9
10
feat: 新功能
fix: 修改bug
docs: 修改文档
style: 格式化代码结构(不影响代码运行的变动)
perf: 性能优化
refactor: 重构(即不是新增功能,也不是修改bug的代码变动,比如重命名变量)
chore: 构建过程或辅助工具的变动(不会影响代码运行)
revert: 回滚到上一个版本。
test: 增加测试。
merge: 代码合并。

4.git reset 回退版本

4.1.git reset <filename> 将commit后unmodified的文件变更为modified

4.2.git reset <commitID> 回到此comiitID提交时的状态

git reset的三种模式 –mixed 、**–soft–hard**
在本地,git会分三个区:工作区、暂存区、本地库

–mixed:保留变更且变更内容处于modified

1
2
3
4
git reset --mixed xxx
#移动本地库HEAD指针
#重置暂存区
#不仅移动了本地库的指针,同时还把暂存区的代码也做了移动。也就是说你上次添加到暂存区的代码,现在变成了红色,即未做【add】操作。如果不写--mixed,默认也是此参数

–soft:保留变更且变更内容处于staged

1
2
3
git reset --soft xxx
#仅仅移动本地库HEAD指针
#仅仅移动本地库HEAD指针,而暂存区和你本地的代码是没有做任何改变的。但是这个时候你上次提交到本地库的代码状态是绿色的,即你未做【commit】操作

–hard:不保留所有变更

1
2
3
4
5
6
git reset --hard xxx
#移动本地库HEAD指针
#重置暂存区
#重置工作区
#不仅移动了本地库的指针,同时还把暂存区的代码也做了移动,同时你本地的代码就是你回退的版本代码

5.git branch 分支

5.1.git checkout -b <新分支><模板分支> 以模板分支为模板,切一个新分支

如果模板不填,则以当前分支为模板

5.2.git checkout -b <新分支> origin <模板分支> 以origin远端仓库模板分支为模板,切一个新分支

5.3.git branch 查看我们当前所处的分支

5.4.git branch <branchName> 切换分支

git merge <branchName> 合并分支变更

注意是是合并变更不是内容

6.git远程仓库

6.1.git push -set-upstream origin <branchName> 将远端origin分支作为本地分支的上流分支

如果我们的本地分支是新切的,即没有设置上流分支,得先执行git push -set-upstream origin &#60;branchName&#62;设置上流分支,执行后远程仓库会新建一个<branchName>分支,git push(git push -u origin branch)就可以顺利将本地变更推送至远端

6.2.git fetch 拉取远端仓库信息:获知远程仓库的分支

如果是fetch下来的分支,自己再git checkout创建相应分支,可以不用设置上流分支-set-upstream来连接远端

7.git pull 相当于先fetch再自动merge

当自己fetch的远端分支被修改后,想将变更代码再次fetch到本地再merge合并,可以用git pull快速实现

8.git log/status/reflog 查看日志/状态/操作记录

8.1.git log 查看git日志

可以看见什么人在什么时间提交了一个什么样的commit,还能查看到每一个commit生成的属于自己的唯一哈希值,可以理解为commit的身份证

8.2.git status 查看git状态

红色字体代表有更新,再通过add后,可变绿

8.3.git reflog 查看所有的操作记录

方便查看commitID的哈希值,虽然只有前7位但已经保证唯一性,想要回到当前分支有更快的方法那就是git pull

9.文件状态 Untracked Unmodified Modified Staged

Untracked未追踪的 Unmodified未修改的 Modified修改过的 Staged暂存状态

1.没有被add过的文件叫untracked
2.add之后文件处于staged状态等待commit
3.commit之后文件处于unmodified
4.当unmodified的文件被修改则会变为modified状态
(但commit想要成功,此文件必须是staged的状态,所以更改过的文件需要重新add,使之从modified状态变更为staged)
5.modified之后的文件add之后将继续变为staged状态
6.unmodifed的文件如果不再需要了,可以remove它不再追踪,使之变为untracked状态

git的4种文件状态

10.git alias 设置命令别名

找到git的etc安装目录,打开gitconfig,设置自己的alias

设置自己的alias

11.git rebase 变基

rebase的原理是枚举变更的commit,依次变基
rebase就是重新排列base,而base就是指commit
git rebase 基,出现冲突解决冲突后将变更add进暂存区,然后执行git rebase --continue继续下一个commit节点的rebase,最后查看log会发现顺序已经变12534

rebase

12.git 分支命名规范

git 分支分为集成分支、功能分支和修复分支,分别命名为 develop、feature 和 hotfix,均为单数,不可使用 features、future、hotfixes、hotfixs 等错误名称。

1.git主分支(master)。它是自动建立,用于发布重大版本更新

2.git开发主分支(develop)。日常开发在此分支上进行

3.git临时性分支:用于应对一些特定目的的版本开发(验证OK后,应该删除此分支),主要有:  

功能(feature)分支:它是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。可以采用feature-的形式命名。

预发布(release)分支:指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支。它的命名,可以采用release-的形式

修补bug(hotfix)分支:软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。修补bug分支是从Master分支上面分出来的。修补结束以后,再合并进Master和Develop分支。它的命名,可以采用hotfix-***的形式。

注意事项: 一个分支尽量开发一个功能模块,不要多个功能模块在一个分支上开发。 feature 分支在申请合并之前,最好是先 pull 一下 develop 主分支下来,看一下有没有冲突,如果有就先解决冲突后再申请合并。

13.git中commit是最重要的

所有的概念都是围绕它展开的,比如分支是commit序列的集合载体,而在执行merge的时候也是针对一个个commit进行合并,执行reset时也是回滚至某个commit,而rebase,它的rebase指的就是commit

参考:https://www.bilibili.com/video/BV1BE411g7SV/?spm_id_from=333.999.0.0&vd_source=d6fd1d657869eff32e2a7ad32e7d535d


Git的常见用法
https://wwwhisperr.github.io/2022/09/24/page/
作者
Whisper
发布于
2022年9月24日
许可协议