首页 > 其他分享 >git 常用指令与简单规范

git 常用指令与简单规范

时间:2023-10-12 15:14:55浏览次数:30  
标签:常用 git -- 修改 指令 提交 commit 分支

1. 前言

随着前端项目数量、前端开发人员、前端业务的日渐增多,则非常有必要整理一份简单的 git 规范,来进行项目开发的规范化约束。本文包括开发常用 git 指令、git 分支管理规范、git 提交规范等。

2. git 常用指令

2.1. 查看最新的远程分支

# 查看远程分支
git branch -r 

# 查看本地和远程所有分支
git branch -a 

2.2. 更新远程服务器分支列表

# 假如别人删除了一些远程分支,我本地git branch -r/a 的时候,会看到删除之前的所有分支
git remote update origin --prune

2.3. 删除本地分支和远程分支

# 删除远程分支:在本地任意非要删除的分支上执行
git push origin --delete 分支名  

# 删除本地分支
git branch -D 分支名

2.4. 修改commit内容

# 如果commit注释写错了,只是想改一下注释,在刚提交之后 执行以下命令
git commit --amend

2.5. 文件恢复

# 1. 已提交:仅恢复已经提交的部分文件
# -- 后面为想要查看单个文件修改历史的文件路径
git log -- src/a.js

## 查出对应修改历史的 hash,并复制

# 恢复某个文件,后面跟文件路径
git checkout 刚才复制的hash src/a.js

# 2. 提交之前:恢复本地所有修改
git checkout .

# 3. 提交之前:回复本地某个文件的修改 或 取消指定文件删除
git checkout  filename

# 4. 恢复到上一个版本,则可以解决整个文件夹删除的修改
git reset --hard HEAD^ 

# 5. 取消本地增加的文件 (慎用!)
git clean -df 

 

2.6. 代码回退

# git reset 不会生成新的提交
git reset --hard HEAD^        # 回退到上个版本
git reset --hard commit_id    # 退到/进到 指定commit_id

# 区别
git reset --soft commit_id # 回到到某个版本,所有后面的修改都在本地暂存区(stage)
git reset --mixed commit_id # 回到到某个版本,所有后面的修改都在本地工作区,未提交到暂存区
git reset --hard commit_id # 回到到某个版本,所有后面的修改都会丢失

# git revert 会生成新的提交
git revert 某次提交的commit_id  # 会仅把该提交的文件恢复,并生成一条新的提交记录

2.7. 强制推送到远程

# 需要在版本仓库开启允许强制推送的权限,且推送后不要再次拉取
git push --force   

2.8. 代码暂存

主要用于当在一个分支的开发工作未完成,却又要切换到另外一个分支进行开发的时候,除了commit原分支的代码改动的方法外,提供暂存代码的方式

git stash 

git stash pop

2.9. 提交记录查看

git log

如果不带任何参数,它会列出所有历史记录,最近的排在最上方,显示提交对象的哈希值,作者、提交日期、和提交说明

如果记录过多,则按Page Up、Page Down、↓、↑来控制显示

按q退出历史记录列表

git log [<options>] [<since>..<until>] [[--] <path>...]

git shortlog

返回每个贡献者的commit次数以及每次commit的commit message

git shortlog

git shortlog -s   # 返回每个作者的贡献次数

git shortlog -sn # 返回每个作者的贡献次数按从多到少排序

git shortlog -sne # 返回每个作者的贡献次数带邮箱按从多到少排序

git shortlog -sn --merges    // 添加一个--no-merges标志,以显示合并提交的次数
 
git shortlog -sn --no-merges // 添加一个--no-merges标志,以忽略合并提交的次数

# 其可以添加参数:
 
# s:省略每次 commit 的注释,仅仅返回一个简单的统计。
# n:按照 commit 数量从多到少的顺利对用户进行排序。
 
# 加上这两个参数之后就可以看到每个用户中的提交次数以及排名情况:
 
# 更详细的参数说明:
 
 -c, --committer       group by committer rather than author
                       按提交人而非作者分组
 -n, --numbered        sort output according to the number of commits per author
                       根据每个作者的提交次数对输出进行排序
 -s, --summary         suppress commit descriptions, only provides commit count
                       抑制提交描述,仅提供提交计数(精简打印数据)
 -e, --email           show the email address of each author
                       显示每个作者的电子邮件地址

git reflog

git reflog 可以查看所有分支的所有操作记录(包括(包括commit和reset的操作),包括已经被删除的commit记录,git log则不能察看已经删除了的commit记录

git reflog 的应用场景:

git reset --hard HEAD~1则 删除了最新一条记录,如果发现删除错误了,需要恢复,这个时候就要使用 git reflog

git reflog 

# 查看当前分支是基于哪个分支checkout的
# show是缺省值,下面命令等同于git reflog 分支名
git reflog show <childBranch>

# 查看 merge 和 checkout 记录
git reflog show --date=local | grep <branchname>

2.10. 合并

merge

将当前分支合并到指定分支。

通过 merge 合并分支会新增一个 merge commit,然后将两个分支的历史联系起来

其实是一种非破坏性的操作,对现有分支不会以任何方式被更改,但是会导致历史记录相对复杂

git merge

git merge --squash branchname  // 可以帮我们将开发分支上的所有内容合并成一次提交到主分支

rebase

rebase 将当前分支移植到指定分支或指定 commit 之上,和 merging 不同,rebasing 清除了历史,因为它完全是从一个分支转移到了另一个分支。在这个过程中,多余的记录被移除了。

rebase 会将整个分支移动到另一个分支上,有效地整合了所有分支上的提交

主要的好处是历史记录更加清晰,是在原有提交的基础上将差异内容反映进去,消除了 git merge所需的不必要的合并提交

git rebase

git rebase -i <commit>  # 移植到指定 commit 上

git rebase --continue  # 用于解决冲突之后,继续执行rebase

cherry-pick

在多分支开发的时候会有需要把一个分支的部分commit应用到其他的分支上,然而git merge会把一个分支的commits 都应用到当前分支,这时候我们可以使用 git cherry-pick ,它的作用是选择已存在的 commit 应用到当前分支上,并产生新的 commit SHA-1 校验和。

git cherry-pick

如果想应用连续的多个commits还可以使用 commit1到 commit1,如果需要包含可以执行 如果只想把某一个分支最后一个commit应用到当前分支,可以直接使用branch-name分支最后一个commit应用到当前分支。

2.11. 查错

# git bisect 用来查找哪一次代码提交引入了错误,它的原理很简单,就是将代码提交的历史,按照两分法不断缩小定位。所谓"两分法",就是将代码历史一分为二,确定问题出在前半部分,还是后半部分,不断执行这个过程,直到范围缩小到某一次代码提交。

git bisect start [终点] [起点]

# 执行上面的命令以后,代码库就会切换到这段范围正当中的那一次提交

2.12. 比较

git diff branch1 branch2 --stat

2.13. tag

# 打 tag 示例
git tag -a v1.1.1 -m msg
git push origin v1.1.1

 

其余还有常用的 git add、git pull、git push、git config 等就不再赘述啦。

3. git 分支管理

  • master:主分支,永远是可用的、稳定的、可直接发布的版本,不能直接在该分支上开发
  • develop:开发主分支,代码永远是最新,所有新功能以这个分支来创建自己的开发分支,该分支只做只合并操作,不能直接在该分支上开发,非必须,看项目需要
  • feature/xxx:功能开发分支,在主分支上创建分支,以自己开发功能模块命名,功能测试正常后合并到主分支)
  • release:预发布分支,在合并好 feature分支的 develop分支上创建,主要是用来提测的分支,修改好 bug 并确定稳定之后合并到develop和master分支,然后发布master分支,适用于多人开发同时提测
  • hotfix/xxx:紧急bug修改分支,在对应版本的 release 分支上创建,流程跟 release分支 相似,修复完成后合并 release 分支,根据情况判断需不需要再合并到 develop 和 master 分支(根据项目需要,可以直接合并到 master)

4. git 提交规范

规范

这里使用 Conventional Commits,它的 message 格式如下:

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
分别对应 Commit message 的三个部分:Header,Body 和 Footer。
  1. Header

Header 部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)。

type: 用于说明 commit 的类型。一般有以下几种:

feat: 新增feature
fix: 修复bug
docs: 仅仅修改了文档,如readme.md
style: 仅仅是对格式进行修改,如逗号、缩进、空格等。不改变代码逻辑。
refactor: 代码重构,没有新增功能或修复bug
perf: 优化相关,如提升性能、用户体验等。
test: 测试用例,包括单元测试、集成测试。
chore: 改变构建流程、或者增加依赖库、工具等。
revert: 版本回滚

scope: 用于说明 commit 影响的范围,比如: views, component, utils, test…

subject: commit 目的的简短描述

  1. body

对本次 commit 修改内容的具体描述, 可以分为多行。如下:

# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# initial commit
  1. Footer

一些备注, 通常是 BREAKING CHANGE(当前代码与上一个版本不兼容) 或修复的 bug(关闭 Issue) 的链接。

commit校验

项目需要先加入 commitlint-config-cz 等校验插件,需按照上述格式填写 commit 信息,或使用格式化工具选择填入,在代码校验完成后,使用 npx git-cz 或 npm run commit 命令,根据提示选择本次修改类型,填入修改内容即可。

5. 注意事项

  • 一个分支尽量开发一个功能模块,不要多个功能模块在一个分支上开发;
  • 严禁所有人员在 master 分支和 develop 分支修改提交代码,master 和 develop(develop 非必须,看项目需要)分支只允许合并;
  • 开发过程中,如果组员 A 开发的功能依赖组员 B 正在开发的功能,可以待组员 B 开发好相关功能之后,组员 A 直接pull组员 B 的分支下来开发,不需要先将组员 B 的分支 merge 到主分支;
  • feature 分支在申请合并之前,先 pull 主分支,看一下有没有冲突,如果有就先解决冲突后再申请合并;
  • master 分支上线后打上 tag,并说明此次详细更改信息,修改时间等;

 

本文是我日常工作中常用 git 命令、git 分支使用规范的简单总结,如有描述不正确的地方,还望大家多多指正,很多命令、概念没有展开描述,大家可以自行学习。 

标签:常用,git,--,修改,指令,提交,commit,分支
From: https://www.cnblogs.com/beileixinqing/p/17759493.html

相关文章

  • Git In Five Minutes (zz)
    //z2014-08-3107:44:[email protected][T7,L125,R6,V74]Git的基本命令:gitpull:从其他的版本库(既可以是远程的也可以是本地的)将代码更新到本地,例如:'gitpulloriginmaster'就是将origin这个版本库的代码更新到本地的master主枝,该功能类似于SVN的updategit......
  • PageOffice6 版本常用事件
    1、AfterDocumentOpened事件打开文件后自动触发的事件是AfterDocumentOpened事件,它通常用于实现文件打开后自动执行某些业务逻辑,比如将默认控件全屏、禁止保存、另存、打印,或者显示或隐藏痕迹等。因此,所有需要在文件打开后自动触发的业务逻辑代码都可以放在此事件中执行。在实......
  • Java常用类,这一次帮你总结好
    常用类概述:内部类Object类包装类数学类时间类字符串StringBuilder和StringBufferDecimalFormat-   一、内部类  -概念:在一个类内部再定义一个完整的类。一般情况下类与类之间是相互独立的,内部类的意思就是打破这种独立思想,让一个类成为另一个类的内部信息,和成员变量、成......
  • GitHub发布2021年度报告:中国开发者数量全球第2 ,最受欢迎的语言是
    临近年底,各大平台年终报告频频发布。作为程序员,应该关注些什么呢?近日,全球最大开发者社区GitHub重磅发布了《2021年度Octoverse报告》,本报告首次结合了来自GitHub上,超过400万个代码库的数据,共有超过12000多名开发者参与问卷调查。在即将过去的2021年,开发者社区发生了哪些有趣......
  • 开发人员常用Docker指令
    开发人员在使用Docker进行应用程序开发和部署时,常用的Docker指令可以分为以下几类:容器管理指令:dockerrun:创建并运行一个新的容器。dockerstart:启动一个已经停止的容器。dockerstop:停止一个正在运行的容器。dockerrestart:重启一个正在运行的容器。dockerpause:暂停一个......
  • Sring boot项目maven常用配置
    <?xmlversion="1.0"encoding="UTF-8"?><projectxmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/......
  • 初次运行 Git 前的配置
    既然已经在系统上安装了Git,你会想要做几件事来定制你的Git环境。每台计算机上只需要配置一次,程序升级时会保留配置信息。你可以在任何时候再次通过运行命令来修改它们。Git自带一个gitconfig的工具来帮助设置控制Git外观和行为的配置变量。这些变量存储在三个不同的......
  • 如何将一个空目录添加到Git仓库?
    内容来自DOChttps://q.houxu6.top/?s=如何将一个空目录添加到Git仓库?如何在Git仓库中添加一个空目录(不包含任何文件)?另一种让目录(在仓库中)保持(几乎)空的方法是在该目录中创建一个.gitignore文件,其中包含以下四行:#忽略此目录中的所有内容*#除了这个文件!.gitignore这......
  • git的使用
    #1协同开发,版本管理#2svn(集中式管理),git(分布式管理)#3git装完,既有客户端,又有服务的#4git工作流程 -工作区,暂存区,版本库#5远程仓库:github,码云,公司内部(gitlab)#6安装:一路下一步#7右键--gitbashhere#8git命令 -初始化:gitinit文件夹名-初始化:gitinit#当前路径......
  • git多分支、git远程仓库、ssh方式连接远程仓库、协同开发、冲突解决
    git多分支 ##命令操作分支-1创建分支gitbranchdev-2查看分支gitbranch-3分支合并(可能经常用)gitmergedev#需要在master分支上,合并dev-4删除分支gitbranch-d分支名#不能在当前分支上,删除当前分支......