深入浅出git-log之代码统计实战

–
git-log 即检察 git 提交日记，本文会全面解析 git-log 使用并通过一个真实的 SpringBoot 项目举行实战。如果你是个技能管理者，你肯定在乎部下做了什么，提了多少代码，是否有“佛祖保佑”，git-log 都可以帮你搞定。它还可帮你 code review，帮你 blame someone。你想 blame 吗？你想快速定位你的代码吗？那就看看我们的 git log 到底能做点啥吧。Let’s Go~
概要

$ git log [] [] [[–]     …]  

• 本文会用到以下两种命令做 demo，一种普通 log，一种单行体现 log
  

普通log

$ git log
单行体现

$ git log --oneline
选项options

• –follow:会追溯历史，包括重命名前的记录
  

$ git log -p gradle.properties
不带 follow参数的情况下，git把名为gradle.properties的文件全部提交记录找出来

$ git log -p --follow gradle.properties
带follow参数的情况下，git会把当前以及重命名前的文件提交记录找出来

• –no-decorate:不体现的所有提交的引用名称
  

$ git log --no-decorate
commit hash
Author: caining demo@gmail.cn
Date: Tue Apr 20 11:10:53 2021 +0800
develop2

• –decorate[=short|full|auto|no]:体现的所有提交的引用名称
  
• 名词解释：Git Reference
  
• Git Reference简写为refs
  
• 本地分支的Reference格式：refs/heads/<local_branch_name>如refs/heads/master，在保证唯一的情况下可以简写为master；
  
• 远程追踪分支的Reference格式：refs/remotes/<remote_repository>/<remote_branch_name>：如refs/remotes/origin/master，在保证唯一的情况下可以简写为origin/master；
  
• tag的Reference格式：refs/tags/<tag_name>：如refs/tags/v1.0.1，在保证唯一的情况下可以简写为v1.0.1
  
• 特殊refs-HEAD，指向当前本地分支的当前commit状态
  
• 特殊refs-FETCH_HEAD，指向当前本地分支在最近一次fetch利用时得到的commit状态
  
• 特殊refs-ORIG_HEAD，指向任何merge或rebase之前的刚刚检出时的commit状态
  

$ git log --decorate=full
结果：HEAD -> refs/heads/develop , refs/remotes/origin/develo

$ git log --decorate=short
结果：HEAD -> develop, origin/develop

• –source:均体现提交分支
  

每个提交均体现提交分支

$ git log --oneline --source
6256aa140 HEAD (HEAD -> develop, origin/develop) message

• –log-size:是该提交消息的长度（以字节为单元）
  

$ git log --oneline --log-size
commit 6256aa140f910d81eb71a7651aad1d6bc5128da0 (HEAD -> develop, origin/develop)

log size 107

Author: caining oslankachina@gmail.com

Date: Thu Apr 22 09:59:29 2021 +0800

message

• -L,::检察某个文件某几行范围内的修改记录
  

$ git log -L 1,1:README.md

• -L:::追踪一个函数的变动历史
  
• 为了保证该命令执行有用，Git 需要知道哪些行是函数声明。Git有一套默认的正则表达式，但是由于语言比力多，默认配置下可能碰到这种报错：fatal: -L parameter ‘test’ starting at line 1: no match
  
• 分析缘故起因：在某些语言中，Git 默认的正则表达式无法识别该语言的函数开始和竣事标识导致无法匹配函数名称
  
• 解决方法
  
• 项目下新建.gitattributes文件 关于gitattributes
  
• 配置对应语言的diff*.java diff=java
  

$ git log -L :test:app/src/main/java/com/cnn/androidmavenpackage/MainActivity.java
重点-筛选

• 请注意，这些是在提交顺序和格式设置选项（例如–reverse）之前应用的。体现提交日记，以下 a b c 均为提交节点 hash 值 commit 时间 a < b < c )
  

普通log

$ git log
单行体现

$ git log --oneline
列出a到(画重点：理解^ 可以理解为from 前面大 背面小，…可以理解为to 前面小背面大)

$ git log a…b
$ git log b ^a
#列出所有可以从a 到 b而不包罗c之前的提交
$ git log a b ^c

• 数量筛选
  

$ git log -3
$ git log -n3
$ git log --max-count=3
-

-n

–max-count=

–skip=

$ git log --skip=3 #跳过3条记录

• 时间筛选
  

$ git log --since=‘2021-04-02 00:00:00’
–since=

–after=

$ git log --until=‘2021-04-02 00:00:00’
–until=

–before=

2周内的提交

$ git log --since=2.weeks = $ git log --since=“2 weeks ago”
2月内的提交

$ git log --since=2.months = $ git log --since=“2 months ago”
1年内的提交

$ git log --since=1.year = $ git log --since=“1 year ago”

• 作者筛选
  

$ git log --author=‘caining’
–author=

–committer=

注意这里是正则，含糊匹配，

如果是多个人人一起查按下面

$ git log -author=“name1|name2|name3”

• 提交形貌筛选
  

$ git log --grep=‘bug fix’
$ git log -i --grep=“message1|message2”
–grep=

重点1： --all-match 可以理解为sql-and与 --grep 至少有一个匹配的提交 例如与-author混用时

$ git log --author=‘caining’ --all-match --grep=‘bug fix’
重点2： --invert-grep 用法同上，可以理解为sql not --grep 至少有一个不匹配的提交 例如与-author混用时

$ git log --author=‘caining’ --invert-grep --grep=‘bug fix’
#上句理解： 为caining 提交的 但是 形貌里不包罗 bug fix的 提交内容

• 代码内容搜索 -S，注意这个搜索可能很耗时。
  

$ git log -S hello

• 多条件混合筛选
  

$ git log --since=1.year --author=‘caining’ --grep=‘获取’ -3

format与样式

• –pretty[=
  
• –date=：--date=relative``--date=local``--date=default-local.--date=iso --date=iso8601``--date=rfc``--date=short``--date=rfc2822
  

日期格式化

• –parents
  

体现提交的父母节点

• –children
  

体现提交的孩子节点

• –graph
  

–graph like this

• git log --pretty=format 已存在样式包罗 oneline,short, medium, full, fuller, reference, email, raw
  

$ git log --pretty=oneline
样式:



$ git log --pretty=short
样式:

commit

Author:



$ git log --pretty=medium
样式:

commit

Author:

Date:





$ git log --pretty=full
样式:

commit

Author:

Commit:





$ git log --pretty=fuller
样式:

commit

Author:

AuthorDate:

Commit:

CommitDate:

• 自定义git log --graph --pretty=format:‘’
  

#%Cred 切换至红色
#%Cgreen 切换至绿色
#%Cblue 切换至蓝色
#%C(yellow)切换至黄色
#%Creset 重设颜色
$ git log --graph --pretty=format:‘%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ --abbrev-commit

• format支持的类型如下，以%开头：
  

%H:完备哈希字串

%h:简短哈希字串

%T:树对象（tree）的完备哈希字串

%t:树对象的简短哈希字串

%P:父对象（parent）的完备哈希字串

%p:父对象的简短哈希字串

%an:作者（author）的名字

%aN:作者（author）的名字 (respecting .mailmap, see [git-shortlog1] or [git-blame1])

%ae:作者电子邮件

%aE:作者电子邮件 (respecting .mailmap, see [git-shortlog1] or [git-blame1])

%al:作者电子邮件的本地部分（@号之前的部分）

%aL:author local-part (see %al) respecting .mailmap, see [git-shortlog1] or [git-blame1])

%ad:作者日期 (format respects --date= option)

%aD:author date, RFC2822 style

%ar:作者日期，相对

%at:作者日期，UNIX时间戳

%ai:author date, ISO 8601-like format -作者日期，类似IS0 8601的格式

%aI:author date, strict ISO 8601 format - 作者日期，严酷的lS0 8601格式

%as:作者日期，短格式（YYYY-MM-DD）

%cn:提交者名称

%cN:committer name (respecting .mailmap, see [git-shortlog1] or [git-blame1])

%ce:提交者电子邮件

%cE:committer email

%cl:committer email local-part

%cL:committer local-part

%cd:committer date (format respects --date= option)

%cD:committer date, RFC2822 style

%cr:committer date, relative

%ct:committer date, UNIX timestamp

%ci:committer date, ISO 8601-like format

%cI:committer date, strict ISO 8601 format

%cs:committer date, short format (YYYY-MM-DD)

%s:message

$ git log --graph --pretty=format:‘提交:-:%Cred%h%Creset;%Cgreen日期:-:%ar%Creset;%Cblue日期at:-:%at%Creset;%C(yellow)日期ai:-:%ai%Creset;%Cred日期ad:-:%ad%Creset;%Cblue作者an:-:%an%Creset;%C(yellow)作者aN:-:%aN%Creset;%Cgreen邮箱ce:-:%ce%Cresete:-:%e;sssss:-:%Cred%s%Creset;SSSS:-:%S;f-%f%n’

git shortlog–统计

默认以贡献者分组举行输出

$ git shortlog
列出提交者代码贡献数量, 打印作者和贡献数量

$ git shortlog -sn==git shortlog -s -n
$ git log --pretty=‘%an’ | sort | uniq -c | sort -k1 -n -r | head -n 10
#-s 参数省略每次 commit 的注释，仅仅返回一个简朴的统计。
#-n 参数按照 commit 数量从多到少的顺遂对用户举行排序
以提交贡献数量排序并打印出message

$ git shortlog -n
采用邮箱格式化的方式举行检察贡献度

$ git shortlog -e
$ git shortlog -sn==git shortlog -s -n
&&

$ git log --pretty=‘%an’ | sort | uniq -c | sort -k1 -n -r | head -n 10
git blame–查提交

检察 README.md 文件的修改历史记录，包括时间、作者以及内容

git blame README.md
检察谁改动了 README.md 文件的 11行-12行

git blame -L 11,12 README.md
git blame -L 11 README.md # 检察第11行以后
体现完备的 hash 值

git blame -l README.md
体现修改的行数

git blame -n README.md
体现作者邮箱

git blame -e README.md
自我先容一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到如今。
深知大多数初中级Android工程师，想要提升技能，每每是自己摸索发展或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技能故步自封！
因此网络整理了一份《2024年Android移动开发全套学习资料》，初衷也很简朴，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻各人的负担。

既有得当小白学习的零基础资料，也有得当3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比力大，这里只是将部分目次截图出来，每个节点里面都包罗大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会一连更新！
如果你以为这些内容对你有帮助，可以扫码获取！！（备注：Android）

题外话

我们见过很多技能leader在口试的时候，碰到处于迷茫期的大龄程序员，比口试官年龄都大。这些人有一些共同特性：可能工作了7、8年，还是天天重复给业务部分写代码，工作内容的重复性比力高，没有什么技能含量的工作。问到这些人的职业规划时，他们也没有太多想法。
实在30岁到40岁是一个人职业发展的黄金阶段，肯定要在业务范围内的扩张，技能广度和深度提升上有自己的筹划，才有助于在职业发展上有一连的发展路径，而不至于故步自封。
不断奔跑，你就知道学习的意义地点！
   注意：我们之前由于秋招网络的二十套一二线互联网公司Android口试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包罗Android基础知识点、Android扩展知识点、Android源码解析、计划模式汇总、Gradle知识点、常见算法题汇总。）
  

《Android学习笔记总结+移动架构视频+大厂口试真题+项目实战源码》，点击传送门即可获取！

，肯定要在业务范围内的扩张，技能广度和深度提升上有自己的筹划，才有助于在职业发展上有一连的发展路径，而不至于故步自封。
不断奔跑，你就知道学习的意义地点！
   注意：我们之前由于秋招网络的二十套一二线互联网公司Android口试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包罗Android基础知识点、Android扩展知识点、Android源码解析、计划模式汇总、Gradle知识点、常见算法题汇总。）
  [外链图片转存中…(img-BVlTqWDs-1712468519826)]
《Android学习笔记总结+移动架构视频+大厂口试真题+项目实战源码》，点击传送门即可获取！


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。