开发工具: git 10、对本地不规范的提交历史进行修改和调整

Git提交了敏感信息,通过BFG工具撤回或修改很久之前已经提交的内容 这篇文章的由来,由于自己在提交代码的时候不小心把服务器的ip地址,还有数据库的密码给push到github上面去了。那么问题来了,我这个已经是一个月之前的提交的呢,现在还能改吗?别慌答案当然是可以的! 阅读详情

1.对上一次 commit 的备注或者代码进行修改

比如张三刚刚执行了一个不规范的commit备注
25
26
修改提交备注:

git commit --amend

27
通过该命令直接就可以修改上一个 commit 的备注信息,补充更多的提交说明。相当于是将上一个 commit 删除掉,然后基于上一个 commit 对应的代码重新构建一个 commit object。

修改后直接通过 git log 查看结果
28
可以发现之前的 SHA-1 值没了,在 “完成部门管理” 这个 commit 上面重新构建了一个 commit object

2.对上一次 commit 加入几行遗漏的代码

比如张三刚执行了一个 commit,结果扫了一眼代码发现今天忘记修改几行代码了,需要修改之后补充到上一个 commit 中去。也可以通过该命令来实现。

首先修改代码,然后加入暂存区,然后再次执行
29
3031
会发现之前的 commit object 也被删除了,构建了一个新的 commit object

查看最近2次的代码差异
32

3.对历史上的多个 commit 进行修改

比如张三可能在本地连续几天都提交了几个 commit,但是一直忘了 push 到远程仓库。突然有一天需要将这个几天的 commit 一次性 push 到远程仓库,但是又发现了 3 天前的某个 commit 备注不规范,需要调整一下。

#该命令只能针对本地最近一次commit去修复
git commit --amend
#调整本地最近3个commit
git rebase -i HEAD~3

张三最近 2 次 commit 都不规范
33
执行如下命令,进入修改界面

git rebase -i head~2

34
将需要调整的 commit 之前的 pick 修改为 edit,然后保存退出,此时工作区的代码:
35
执行 git commit --amend 修改备注。修改完后执行

git rebase --continue

前进到 242f207 的 commit object。可以看到此时的指针是 feature/002 rebase -i 2/2 以及其工作区的状态。
36

再进行 git commit --amend 修改备注后,继续执行 git rebase --continue,此时的指针指向了 feature/002 分支,说明需要进的修改已经全部完毕。
37
最后的日志结果:
38
通过 git rebase --continue 和 git commit --amend,最终会将设置为 edit 的那几个 commit 都修改完毕。

4.对几天前的commit加入代码

如果要对前几天的某个 commit 加入更多的代码,也可以这样做。

先 git rebase -i head~x,选择要修改的 commit,将其从 pick 修改为 edit

然后修改代码,加入暂存区,接着 git commit --amnend,修改 commit 备注,即可以加入代码。或者是直接执行 git commit --amend,修改备注即可。

比如要对 b70b226 的 commit object 的代码进行修改
39

git rebase -i head~7

将其从 pick 改为 edit,修改后保存退出
40
此时的工作区将还原到当时的代码
41
对代码进行修改:
42
加入暂存区后修改备注:
43
44
查看日志
45

修改成功!

一般是不予许对前几天的 commit 加入代码的,除非是特例

比如说3天前些好的某个功能,忘了加一些非核心的代码,如日志代码,监控代码等,那么可以加入这些代码

5.删除 commit 以及调整 commit 的顺序

这个场景存在于比如说偶尔不小心加了一个空行,最后提交了,此时是需要将那个不规范的 commit 给删除掉(如果公司有 git提交规范)。

不小心 commit 了一个不规范的备注
46
之后又在空行的这行写入了其他代码
47
此时的 git log:
48
要删除不规范的 commit 备注,先 rebase 到该 commit
50
需要解决冲突,此时的工作区代码:
51
解决冲突:
52
再 git add --all . 和 git commit -m “解决冲突”,查看日志
53
会发现不规范的 commit 已经被删除了

6.将多个 commit 合并为一个commit

push 到远程仓库之前要将今天的多个 commit 合并在一起的。因为一般一天只能有一个 commit

比如第一个 commit
54

第二个 commit:
55
56

git rebase -i head~2

进入编辑页面,将 pick 改为 squash
57
保存后退出
58
根据提示,应该包含前面 3 个而不是 2 个

# 先撤销
git rebase --abort

# 再次进入编辑页面
git rebase -i head~3

59
保存后将自动进入编辑页面,然后将 commit 备注全部重新写一个 commit60
查看今天和 commit 和昨天的 commit 之间的差异61

注意:如果要合并多个 commit,那么一定要往前多选择一个 commit

7.将一个commit切分为多个commit

比如说你好几天没有合并代码,然后突然有天不小心将3天修改的代码都合并成了一个 commit 了,此时木已成舟,没法用 git add -i 来多次 commit 了。这时就需要将这个 commit 拆分为多个 commit,还是在上面那个界面,将要拆分开来的 commit 前面的指令,修改为edit然后你就会回到那个 commit 对应的版本,此时执行 git reset HEAD^,此时会直接回退到之前的状态,然后此时可以执行多次 git add 和 git commit,形成多个commit 接着最后执行 git rebase --continue 结束这次 commit 拆分

比如说要将 a4c7 的 commit 拆分成 2 个 commit
62
首先执行如下命令,进入编辑页面,将要修改的 commit 的 pick 改为 edit

git rebase -i head~2

63
64
查看状态,发现此时的Main文件已是modified状态
65
加入一行代码,表示拆分功能1
66
此时 2 个文件都是 modified
67
将 Employee 文件放入暂存区,表示拆分的功能 1 已被拆分完毕
68
69
然后再将 Main 文件存入暂存区,表示功能 2 拆分完毕。

完成后执行 git rebase --continue 完成全部操作
70
此时的 log
在这里插入图片描述
可以看到已完成拆分

Git提交信息规范实操:从amend到批量修改作者信息 本文详细介绍了Git提交信息规范的重要性及实操技巧,包括使用`git commit --amend`快速修正最近提交、`git rebase -i`交互式变基修改历史提交,以及批量修改作者信息的高级方法。通过规范提交信息和掌握历史重写技术,团队可以维护清晰可读的版本历史,提升协作效率。 阅读详情

相关推荐

双向全桥隔离DC-DC变换器(DAB)的调制优化与挑战解析

本文深入解析了双向全桥隔离DC-DC变换器(DAB)的核心调制技术及其面临的挑战。文章从基础的相移调制(SPS)入手,逐步探讨了扩展相移(EPS)、双重相移(DPS)等进阶策略,并重点分析了电流优化与零电压开通(ZVS)等硬核优化技巧。针对DAB在实际应用中存在的建模困难、多模块并联及数字实现等挑战,提供了实用的应对策略与设计思路,旨在帮助工程师在性能、复杂度与成本之间找到最佳平衡。

weixin_29271053的博客 570

git commit提交不规范,需要修改历史commit

【代码】git commit提交不规范,需要修改历史commit。

qq_53696987的博客 700

OpenSSH命令注入漏洞复现(CVE-2020-15778)

OpenSSH命令注入漏洞复现 1、简介 OpenSSH 是 SSH (Secure SHell) 协议的免费开源实现,ssh主要就是用来远程控制计算机,或传输文件,OpenSSH是使用SSH透过计算机网络加密通讯的实现。 2、漏洞概述 该漏洞是存在于scp在拷贝文件时产生的一个代码注入漏洞,攻击者可以利用此漏洞执行任意命令,比如:反弹shell, 3、影响版本 openssh <= openssh-8.3p1 4、实验环境 首先下载openssh,版本要符合漏洞影响的版本 服务端:apt-get

weixin_44537595的博客 3637

git commit 内容不合规,代码提交不上去,怎么办

git commit 内容提交不上去,怎么办,可以试试 git commit --amend 和 git reabase 来修改commit内容

wangqiaojie的博客 4758

BRAM在图像处理缓存中的实现:完整示例解析

深入讲解如何利用BRAM高效实现图像处理中的数据缓存,结合实际案例解析BRAM的应用优势与设计细节,提升系统性能。

weixin_29443363的博客 332

用Multisim和AD2复刻经典:手把手教你搭建μA741三角波-方波发生器(附完整避坑指南)

本文详细介绍了如何使用Multisim和AD2搭建基于μA741运算放大器的三角波-方波发生器,包括电路原理、Multisim仿真流程、AD2硬件搭建及调试技巧。通过对比理论计算、仿真和实测数据,深入分析器件非理想特性的影响,并提供16个典型问题的解决方案,帮助读者掌握波形发生器的设计原理和工程调试经验。

weixin_28744423的博客 284

【前端】代码Git提交规范之限制非规范化提交信息

在我们目前的前端项目中,我们采用git作为版本控制工具。使用git管理项目意味着我们经常需要提交代码。当我们执行命令时,我们被要求提供一个描述信息。现在使用约定式规范提交,和Commitizen简化提交流程,但是如果出现人就是不遵守规则该怎么办呢?

Yong.Sunshine 1936

宇树G1开发实践--PPT汇报(基础版)

本文介绍了一套基于宇树G1人形机器人的PPT自动演示系统,可实现"一键启动、自动演讲"功能。系统通过多线程同步技术,将音频播放与机器人动作完美结合,支持12种预设社交互动动作。硬件依赖宇树G1机器人、外接音响和网络连接,软件采用Python SDK和ALSA音频工具。核心功能包括音频文件自动排序、外接音响播放控制、机器人动作执行及音画同步。使用时需配置网络接口和音频设备号,运行后自动按顺序播放音频并执行随机动作。系统特别强调了安全注意事项,并提供了常见问题解决方案,适用于展会、汇报等需要

m0_47999117的博客 510

git修改本地及远程历史commit提交信息

修改最近提交 背景:发现已经push到远程分支的commit信息不够规范,想要将其覆盖,而不是添加多一条新的commit信息。 法一: “git commit --amend” 该命令可修改最近一次提交的提交信息。 若想修改最近一次提交的内容: 修改内容后暂存它们,然后再用该命令提交新的内容,以替换掉旧的最近一次提交。 一般内容修改后,commit的信息也会有修改的需求。如果不想修改提交信息,仅仅是修改了内容: 同样是修改内容后暂存它们,然后通过以下命令避免不必要的编辑器环节即可: git com

YumEllen的博客 6540

self‑improving‑agent 安装与配置指南(OpenClaw)

长期记忆错误反思用户偏好学习持续进化AI → 反思 → 学习 → 改进。

tiantiantbtb的博客 1337

11.Labview实现用户界面切换的几种方式---通过VI间相互调用

本文介绍了界面切换的几种方式,分别是重入和引用①重入方式可以通过调用子VI的方式打开被调用的界面,往往应用于弹窗等的设置程序。②引用方式分两种,一种是打开引用,一种是静态引用。区别在于打开引用需要设置被打开VI的目标地址,静态引用仅需在引用时绑定VI的位置即可。③推荐使用静态引用的方式切换界面。④使用引用打开界面时,需通过属性节点和调用节点来设置程序的状态。更多内容欢迎大家补充和留言讨论~本文介绍了GUI界面设计相关的程序,更多相关文章后续持续更新,请关注作者不迷路~本期就到这里,再见~

关注我,更多技术问题欢迎私聊~ 9542

Git 提交规范

Git 提交规范,包含命令行、Commitizen、 [git-commit-plugin、idea插件Git Commit Template

半夏_2021的博客 3万+

Spring AI提示词模板应用

本文介绍了使用SpringAI提示词模板的配置方法,主要步骤包括:1)在JDK17和SpringBoot3.4.4环境下引入spring-ai-alibaba1.0.0.2依赖;2)配置application.yml文件;3)创建测试控制器类处理提示词模板(.st文件);4)通过模板变量动态生成AI回复内容。演示了如何通过@RequestParam设置默认参数,实现无需前端传参即可测试AI回复功能,最终完成了一个SpringAI提示词模板的应用Demo。

wjianwei666的专栏 196

Git提交:规范化你的代码历史

在开发过程中,`git commit` 是每个开发者都会频繁使用的命令。一个清晰、规范的提交信息不仅能够提升团队协作效率,还能让代码历史更容易被理解和追溯。

XuanRan的博客 4281

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

【软件开发规范篇】Git代码提交规范

本文介绍软件项目开发过程中,代码提交到git仓库,建议遵循的一些规范。每次提交代码到 Git 仓库时,都需要写 commit message。通常情况下,commit message 应该清晰明了,说明本次提交的目的和具体操作等。然而,在日常开发中,开发者们提交的 commit message 千差万别,中英文混用,导致后续代码维护成本很高,有时候甚至自己都不知道修复的是什么问题。因此,为了解决这些问题,建议大家在提交代码的时候,能遵循一些规范或约定,从而提高代码规范,提高开发效率。

分享是一种境界,勤于分享,乐于分享! 5018

Outlook Express 6 (OE6) for Win7/Win8/Win10

英文版 Outlook Express6.0, 兼容Win7/Win10/WinXP,解压就可用。

Git Commit 提交规范

Git Commit 规范是一套约定俗成的规则,用于统一代码提交信息的格式和内容。它可以帮助团队更清晰地记录代码变更历史,方便回溯问题、生成更新日志(CHangelog)或自动化版本管理。一个规范的 Commit Message 通常包含和指明本次提交的featfixdocsstylerefactortestchoreperfcirevertfeat(user)fix(api)featfixfeatfix。

fushan2012的博客 3154

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

Git代码提交信息规范

git提交代码信息规范

卓越之识论道,平常之识论事,狭隘之识论人 1957

Git 提交信息规范

Git 提交信息即每次进行 Git 提交时,需要编写的提交说明。本文对一些主流的 Git 提交信息规范进行了整理,并基于 Conventional Commits(约定式提交)规范我们的 Git 提交信息。

YMGogre的博客 1648

GIT提交规范

良好的Git提交日志非常重要,最明显的一点是,它让整个Git提交历史的阅读变得非常轻松

佐斌的笔记簿 913

Git提交规范及最佳实践

将价格计算从 ShoppingCartService 移至独立的 PriceCalculator 类,- 修复 tree-shaking 对 lodash 的兼容性问题。❌ 错误:"修复了XXX问题" → ✅ 正确:"修复XXX问题"当用户频繁点击发送验证码按钮时,后端未正确校验时间间隔,revert: 撤销 "feat: 实验性分页功能":描述时用 "新增/修复/优化/调整" 等祈使动词。perf(图片加载): 启用 WebP 格式压缩。fix(登录): 修复手机号验证码重复发送问题。

BillKu的博客 3333

Git 工程化之提交规范

Git 提供了多种不同类型的钩子(hooks),可以在特定的操作时执行自定义的脚本或命令sql代码解读复制代码。

weixin_47588164的博客 3225

详细的Git 代码提交规范

Git提交规范指南:核心在于通过标准化的提交信息(类型+描述)形成清晰的项目历史。常用类型包括feat(新功能)、fix(bug修复)、docs(文档更新)等,提交信息包含标题、正文和页脚三部分。标题格式为"类型(范围):描述",使用祈使句;正文说明修改原因;页脚标注重大变更或关联Issue。建议保持原子性提交,使用工具辅助规范,并与工作流结合。实际应用中可简化格式,按团队需求调整规范。

念旧的博客 2697

【规范】看看人家Git提交描述,那叫一个规矩

1.IDEA Git描述规范插件:git commit message helper 2.Git提交描述格式规范,type、scope、subject、body、footer内容分析 3.实例Git提交描述解析:新功能提交、bug修复、文档提交

JavaDog程序狗 2253

Git-knife:像编辑电子表格一样批量修改Git提交历史

在软件开发和团队协作中,版本控制系统是管理代码变更的核心工具,其提交历史记录了项目的完整演进脉络。Git作为分布式版本控制系统的代表,其提交历史包含了代码快照、作者、日期和提交信息等关键元数据。然而,当需要批量修正历史提交中的作者信息、统一提交信息格式或清理不规范记录时,直接操作Git底层命令不仅复杂且易出错。Git-knife正是为解决这一工程痛点而设计的工具,它创新性地将Git提交历史导出为CSV文件,允许用户在熟悉的电子表格界面中进行直观的批量编辑,再安全地导回并重写历史。这种将高级Git操作简化为数

weixin_30653023的博客 464

为什么我们需要 Git 提交规范?——从一段“无注释”提交记录说起

接手缺乏文档的老项目时,Git提交记录往往存在"无注释"或"过于简略"的问题,导致历史追溯困难、协作效率低下和维护成本增加。解决方案是采用结构化提交规范:提交信息应包含类型(如feat/fix)、范围、主题三部分,正文详细说明修改内容,页脚标注关联信息。规范的提交信息能清晰记录代码演变过程,降低团队协作成本,是项目可持续发展的重要基础。建议团队建立提交规范文化,避免无意义提交,让每个提交都能为未来维护提供有效信息。

qq_43258077的博客 1939
上一篇: 开发工具: git 09、feature分支开发到一半时切换到bugfix分支
下一篇: 开发工具: git 11、对本地刚做出的修改、暂存和提交进行撤回
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值