Git log 进阶用法(含格式化、以及数据过滤)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: Git log 进阶用法(含格式化、以及数据过滤)

🏆 文章目标:了解学习进阶的Git log用法,用于解决产品发版时的一些需求。

🍀 Git log 进阶用法(含格式化、以及数据过滤)

✅ 创作者:Jay…

🎉 个人主页:Jay的个人主页

🍁 展望:若本篇讲解内容帮助到您,请帮忙点个赞吧,您的支持是我继续写作的最大动力,谢谢。🙏

需求

这篇文章由需求引发的学习,下面是关于Git log的常见需求,大家可以带着这几点疑问,了解Git log的使用方式,主要包含格式化,和数据过滤:

  1. 系统发版时,想要针对特定时间,获取所有的提交记录?
  2. 查看某个人的提交记录,且忽略合并的记录?
  3. 查看提交记录,并且按照自定义格式输出,如 提交信息 提交人

方案

为节省大家的时间,有对应需求的朋友,可以直接使用如下命令。感兴趣的朋友可以继续阅读,了解并使用其他方式。

1、系统发版时,想要针对特定时间,获取所有的提交记录?

git log --oneline --after="2023-3-20" --before="2023-3-27"

2、查看某个人的提交记录,且忽略合并的记录?

git log --oneline --no-merges --author jay

3、查看提交记录,并且按照自定义格式输出,如 提交信息 提交人

git log --oneline --pretty=format:"%cn && %s"

格式化

当需要回顾Git 的Log提交日志时,可以参考如下案例,并可以按照需求格式化Log日志。如下为几种常见的输出案例。

Oneline

–oneline标记把每一个提交压缩到了一行中。它默认只显示提交ID和提交信息的第一行。git log --oneline的输出一般是这样的:

0e25143 Merge branch 'feature'
ad8621a Fix a bug in the feature
16b36c6 Add a new feature
23ad9ad Add the initial code base

它对于获得项目的总体情况很有帮助。

Decorate

很多时候,知道每个提交关联的分支或者标签很有用。--decorate标记让git log显示指向这个提交的所有引用(比如说分支、标签等)。

这可以和另一个配置项一起使用。比如,执行git log --oneline --decorate 会将提交历史格式化成这样:

0e25143 (HEAD, master) Merge branch 'feature'
ad8621a (feature) Fix a bug in the feature
16b36c6 Add a new feature
23ad9ad (tag: v0.9) Add the initial code base

在这个例子中,你(通过HEAD标记)可以看到最上面那个提交已经被checkout了,而且它还是master分支的尾端。第二个提交有另一个feature分支指向它,以及最后那个提交带有v0.9标签。

分支、标签、HEAD还有提交历史是你Git仓库中包含的所有信息。因此,这个命令让你更完整地观察项目结构。

Diff

git log提供了很多选项来显示两个提交之间的差异。其中最常用的两个是--stat-p

--stat选项显示每次提交的文件增删数量(注意:修改一行记作增加一行且删去一行),当你想要查看提交引入的变化时这会非常有用。比如说,下面这个提交在hello.py文件中增加了67行,删去了38行。

commit f2a238924e89ca1d4947662928218a06d39068c3
Author: John <john@example.com>
Date:   Fri Jun 25 17:30:28 2014 -0500
    Add a new feature
 hello.py | 105 ++++++++++++++++++++++++-----------------
 1 file changed, 67 insertion(+), 38 deletions(-)

文件名后面+和-的数量是这个提交造成的更改中增删的相对比例。它给你一个直观的感觉,关于这次提交有多少改动。如果你想知道每次提交删改的绝对数量,你可以将-p 选项传入git log 。这样提交所有的删改都会被输出:

commit 16b36c697eb2d24302f89aa22d9170dfe609855b
Author: Mary <mary@example.com>
Date:   Fri Jun 25 17:31:57 2014 -0500
    Fix a bug in the feature
diff --git a/hello.py b/hello.py
index 18ca709..c673b40 100644
--- a/hello.py
+++ b/hello.py
@@ -13,14 +13,14 @@ B
-print("Hello, World!")
+print("Hello, Git!")

对于改动很多的提交来说,这个输出会变得又长又大。一般来说,当你输出所有删改的时候,你是想要查找某一具体的改动,这时你就要用到pickaxe 选项。

Shortlog

git shortlog是一种特殊的git log ,它是为创建发布声明设计的。它把每个提交按作者分类,显示提交信息的第一行。这样可以容易地看到谁做了什么。

比如说,两个开发者为项目贡献了5个提交,那么git shortlog 输出会是这样的:

Mary (2):
      Fix a bug in the feature
      Fix a serious security hole in our framework
John (3):
      Add the initial code base
      Add a new feature
      Merge branch 'feature'

默认情况下,git shortlog把输出按作者名字排序,但你可以传入-n选项来按每个作者提交数量排序。

Graph

--graph 选项绘制一个ASCII图像来展示提交历史的分支结构。它经常和 --oneline--decorate两个选项一起使用,这样会更容易查看哪个提交属于哪个分支:

git log --graph --oneline --decorate
For a simple repository with just 2 branches, this will produce the following:
*   0e25143 (HEAD, master) Merge branch 'feature'
|\
| * 16b36c6 Fix a bug in the new feature
| * 23ad9ad Start a new feature
* | ad8621a Fix a critical security issue
|/
* 400e4b7 Fix typos in the documentation
* 160e224 Add the initial code base
*

星号表明这个提交所在的分支,所以上图的意思是23ad9ad和16b36c6这两个提交在topic分支上,其余的在master分支上。

虽然这对简单的项目来说是个很好用的选择,但你可能会更喜欢gitk或SourceTree这些更强大的可视化工具来分析大型项目。

自定义格式

对于其他的git log格式需求,你都可以使用--pretty=format:"<string>"选项。它允许你使用像printf一样的占位符来输出提交。

比如,下面命令中的%cn%h%cd这三种占位符会被分别替换为作者名字、缩略标识和提交日期。

git log --pretty=format:"%cn committed %h on %cd"
This results in the following format for each commit:
John committed 400e4b7 on Fri Jun 24 12:30:04 2014 -0500
John committed 89ab2cf on Thu Jun 23 17:09:42 2014 -0500
Mary committed 180e223 on Wed Jun 22 17:21:19 2014 -0500
John committed f12ca28 on Wed Jun 22 13:50:31 2014 -0500

常用的格式选项有:

格式选项 输出结果描述
%H 提交对象的散列值,即:校验和
%h 提交对象的简短的散列值
%T 树对象的散列值
%t 树对象的简短的散列值
%P 父对象的散列值
%p 父对象的简短的散列值
%an 作者的名称
%ae 作者的邮箱
%ad 创作的日期,可使用-data=<选用指定日期格式>
%ar 相当于当前日期的创作日期
%cn 提交者的名称
%ce 提交者的邮箱
%cd 提交日期
%cr 相当于当前日期的提交日期
%s 提交信息的主题(相当于提交时附加的内容)

除了让你只看到关注的信息,这个--pretty=format:"<string>" 选项在你想要在另一个命令中使用日志内容是尤为有用的。

数据过滤

格式化提交输出只是git log其中的一个用途。另一半是理解如何通过一些条件或参数过滤提交历史中的数据。接下来会介绍一些案例:

所有的用法都可以和上面讨论过的格式化选项结合起来。

按数量

git log最基础的过滤选项是限制显示的提交数量。当你只对最近几次提交感兴趣时,它可以节省你一页一页查看的时间。

你可以在后面加上-选项。比如说,下面这个命令会显示最新的3次提交:

git log -3

按日期

如果你想要查看某一特定时间段内的提交,你可以使用–after 或 --before 标记来按日期筛选。它们都接受好几种日期格式作为参数。比如说,下面的命令会显示2014年7月1日后(含)的提交:

git log --after="2014-7-1"

你也可以传入相对的日期,比如一周前(“1 week ago”)或者昨天(“yesterday”):

get log --after="yesterday"

你可以同时提供–before 和 --after 来检索两个日期之间的提交。比如,为了显示2014年7月1日到2014年7月4日之间的提交,你可以这么写:

git log --after="2014-7-1" --before="2014-7-4"

注意--since--until 标记和--after--before标记分别是等价的。

按作者

当你只想看某一特定作者的提交的时候,你可以使用--author标记。它接受正则表达式,返回所有作者名字满足这个规则的提交。如果你知道那个作者的确切名字你可以直接传入文本字符串:

git log --author="John"

它会显示所有作者叫John的提交。作者名不一定是全匹配,只要包含那个子串就会匹配。

你也可以用正则表达式来创建更复杂的检索。比如,下面这个命令检索名叫Mary或John的作者的提交。

git log --author="John\|Mary"

注意作者的邮箱地址也算作是作者的名字,所以你也可以用这个选项来按邮箱检索。

如果你的工作流区分提交者和作者,--committer也能以相同的方式使用。

按提交信息

按提交信息来过滤提交,你可以使用–grep标记。它和上面的–author标记差不多,只不过它搜索的是提交信息而不是作者。

比如说,你的团队规范要求在提交信息中包括相关的issue编号,你可以用下面这个命令来显示这个issue相关的所有提交:

git log --grep="JRA-224:"

你也可以传入-i参数来忽略大小写匹配。

按文件

很多时候,你只对某个特定文件的更改感兴趣。为了显示某个特定文件的历史,你只需要传入文件路径。比如说,下面这个命令返回所有和foo.pybar.py文件相关的提交:

git log -- foo.py bar.py

–告诉git log接下来的参数是文件路径而不是分支名。如果分支名和文件名不可能冲突,你可以省略–。

按内容

我们还可以根据源代码中某一行的增加和删除来搜索提交。这被称为pickaxe,它接受形如-S""的参数。比如说,当你想要知道Hello, World!字符串是什么时候加到项目中哪个文件中去的,你可以使用下面这个命令:

git log -S "Hello, World!"

如果你想用正则表达式而不是字符串来搜索,你可以使用-G "<regex>"标记。

这是一个非常强大的调试工具,它能让你定位到所有影响代码中特定一行的提交。它甚至可以让你看到某一行是什么时候复制或者移动到另一个文件中去的。

按范围

你可以传入范围来筛选提交。这个范围由下面这样的格式指定,其中<since><until>是提交的引用:

git log <since>..<until>

这个命令在你使用分支引用作为参数时特别有用。这是显示两个分支之间区别最简单的方式。看看下面这个命令:

git log master..feature

其中的master..feature范围包含了在feature分支而不在master分支中所有的提交。换句话说,这个命令可以看出从master分支fork到feature分支后发生了哪些变化。它可以这样可视化:

注意如果你更改范围的前后顺序(feature…master),你会获取到master分支而非feature分支上的所有提交。如果git log输出了全部两个分支的提交,这说明你的提交历史已经分叉了。

过滤合并提交

git log输出时默认包括合并提交。但是,如果你的团队采用强制合并策略(意思是merge你修改的上游分支而不是将你的分支rebase到上游分支),你的项目历史中会有很多外来的提交。

你可以通过--no-merges标记来排除这些提交:

git log --no-merges

另一方面,如果你只对合并提交感兴趣,你可以使用–merges标记:

git log --merges

它会返回所有包含两个父节点的提交。

总结

你现在应该对使用git log来格式化输出和选择你要显示的提交的用法比较熟悉了。它允许你查看你项目历史中任何需要的内容。

这些技巧是你Git工具箱中重要的部分,不过注意git log往往和其他Git命令连着使用。当你找到了你要的提交,你把它传给git checkout git revert 或是其他控制提交历史的工具。所以,请继续坚持Git高级用法的学习。


关注公众号:熊猫Jay字节之旅,了解更多 AI 技巧 ~

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
10天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
本文介绍了MySQL InnoDB存储引擎中的数据文件和重做日志文件。数据文件包括`.ibd`和`ibdata`文件,用于存放InnoDB数据和索引。重做日志文件(redo log)确保数据的可靠性和事务的持久性,其大小和路径可由相关参数配置。文章还提供了视频讲解和示例代码。
118 11
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
|
10天前
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的联机重做日志文件与数据写入过程
在Oracle数据库中,联机重做日志文件记录了数据库的变化,用于实例恢复。每个数据库有多组联机重做日志,每组建议至少有两个成员。通过SQL语句可查看日志文件信息。视频讲解和示意图进一步解释了这一过程。
|
1月前
|
数据采集 机器学习/深度学习 存储
使用 Python 清洗日志数据
使用 Python 清洗日志数据
35 2
|
1月前
|
开发工具 git
git显示开发日志+WinSW——将.exe文件注册为服务的一个工具+图床PicGo+kubeconfig 多个集群配置 如何切换
git显示开发日志+WinSW——将.exe文件注册为服务的一个工具+图床PicGo+kubeconfig 多个集群配置 如何切换
38 1
|
2月前
|
安全 网络安全 开发工具
深入探索Git:全面解析Git的用法与最佳实践
深入探索Git:全面解析Git的用法与最佳实践
57 2
|
3月前
|
存储 消息中间件 人工智能
AI大模型独角兽 MiniMax 基于阿里云数据库 SelectDB 版内核 Apache Doris 升级日志系统,PB 数据秒级查询响应
早期 MiniMax 基于 Grafana Loki 构建了日志系统,在资源消耗、写入性能及系统稳定性上都面临巨大的挑战。为此 MiniMax 开始寻找全新的日志系统方案,并基于阿里云数据库 SelectDB 版内核 Apache Doris 升级了日志系统,新系统已接入 MiniMax 内部所有业务线日志数据,数据规模为 PB 级, 整体可用性达到 99.9% 以上,10 亿级日志数据的检索速度可实现秒级响应。
AI大模型独角兽 MiniMax 基于阿里云数据库 SelectDB 版内核 Apache Doris 升级日志系统,PB 数据秒级查询响应
|
3月前
|
jenkins 持续交付
jenkins学习笔记之三:使用jenkins共享库实现日志格式化输出
jenkins学习笔记之三:使用jenkins共享库实现日志格式化输出
jenkins学习笔记之三:使用jenkins共享库实现日志格式化输出
|
3月前
|
缓存 NoSQL Linux
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
128 1
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
|
3月前
|
数据采集 监控 数据安全/隐私保护
掌握Selenium爬虫的日志管理:调整–log-level选项的用法
在Selenium Web数据采集时,日志管理至关重要。通过调整`–log-level`参数可优化日志详细度,如设置为`INFO`记录一般操作信息。结合代理IP、Cookie及user-agent配置,不仅能提高采集成功率,还能规避反爬机制。合理选择日志级别有助于调试与性能平衡,在复杂的数据采集任务中保持程序稳定与可控。
123 1
掌握Selenium爬虫的日志管理:调整–log-level选项的用法
|
2月前
|
SQL 人工智能 运维
在阿里云日志服务轻松落地您的AI模型服务——让您的数据更容易产生洞见和实现价值
您有大量的数据,数据的存储和管理消耗您大量的成本,您知道这些数据隐藏着巨大的价值,但是您总觉得还没有把数据的价值变现出来,对吗?来吧,我们用一系列的案例帮您轻松落地AI模型服务,实现数据价值的变现......
194 3