Github对Git commit date操作的诸多细节,你注意到了么

简介: 我们开发人员几乎每天都要使用git commit,但你知道他对时间处理的一些细节吗?一起来了解一下吧

git log是再常见不过的一个git命令,通常情况下他的标准输出格式如下:

commit [commit id]
Author: [user id] <[user email]>
Date: [commit date]

    [commit msg]

...

在进行commit操作时候,除了commit id以外,其余的信息都是可以用扩展参数修改的:

内容 参数 格式
Author --author --author="[user id] <[user email]>"
Date --date 格式丰富,参考文章详解git commit --date的参数格式
Message -m -m "[msg]"(必填项,但可以使用--allow-empty-message参数忽略必填要求)

格式丰富多样的Date便是本文的主题,使用--date参数马上就可以看到效果,无论在提交后的成功消息,还是在git log都可以看到已经是自己在--date参数指定的日期了,也许你会有这样的想法,如果我有一个repo的log是这样的:

  • 3月1日 初始化repo
  • 3月3日 添加文件

在3月4日,我提交一个--date指定为3月2日的commit会怎么样呢?其实不用想,git log不会按时间排序的,commits树对象结构上本身就是有序的,按照默认的存储循序,他会做如下显示:

  • 3月1日 初始化repo
  • 3月3日 添加文件
  • 3月2日 修改文件

当然对于托管网站来说,这是个值得讨论的问题,这也是我很多年前关心的一个事,可以在一个各路神仙云集的repo上,也就是 https://github.com/isaacs/github 上找到一个相关的issue,一直讨论这个log日期排序的问题,已经open了整整六年之旧,近两年还有人讨论(当然2013年开到现在还没关的issue也有三页多),至今尚未close,具体的link我就不放了,因为isaacs是值得所有前端开发人员尊敬的人物,在他的issue列表中找一找也是无可厚非,这是个玩笑。具体原因是这个issue的creator是一个典中之典的人,精神上疯疯癫癫的长期信邪教从最近的文字上看有些神志不清的样子,实在没法把包含他内容的link放我的文章,最重要的是很多与他相关的issue因为完全违背isaacs对这个repo讨论的原则要求而被close掉,那么基本的要求都做不到,可见真的宛若野人,完完全全可以isaacs的一段话形容他:

Trolling, disparaging remarks about GitHub, or even just unproductive kvetching

不过由于这个issue下面有很多人很好的解释了什么叫做procedural knowledge,想看可以慢慢找,说远了,话说回来push到Github后会发现还有另外一个问题,看到用--date指定日期后的commits,Gitlab的用户十分满意,Github的用户却犯了愁,这是为什么呢?

Github用户打开repo的Commits视图,发现经过修改的date提交到Github中心之后,发现Github并没有理会--date参数,而是使用了执行git commit命令时的时间,让人怀疑哪里出了问题,但回到自己Github个人中心的主界面,俨然发现在绿油油的contributions图,刚才的commit记录显示的却是--date指定的时间,这非常矛盾。而Gitlab用户并没有遇到这样的问题,他们在Gitlab任何界面看到关于经过修改--date后的那条commit的信息,都显示的是自己--date指定的时间。

原因是Git对commit的记录其实有两套日期,分别是AuthorDate和CommitDate,--date参数只修改了AuthorDate,而没有修改CommitDate,而且CommitDate是没有参数可以设定的,这两个时间都会被推送给远程,Github在commits视图使用的就是CommitDate,这让Github用户很懊恼,要早知道就好了,而且为什么别人Gitlab全都用AuthorDate呢?当然这些也没法细究了。

那么,git commit命令没有参数可以设置CommitDate,开发者们就真的无法修改CommitDate了吗?或者说只能修改git源码?其实并不是,这两个日期都有对应的环境变量,进行如下export即可:

#Commit Date
export GIT_COMMITTER_DATE="[date]"

#Author Date
export GIT_AUTHOR_DATE="[date]"

这下可以不用--date参数了,而且环境变量中设置日期的格式和 详解git commit --date的参数格式 一文提到的是一样的,export好环境变量之后就可以commit了,push后就可以在Github的commits界面看到自己设定的时间了。

使用Windows的开发人员应该注意,几乎可以说,有关git的一切环境变量,都应该在git-bash中乖乖的使用他们嫁接好的export命令,或者是用WSL,Cygwin等等的类Unix模拟终端。git-for-windows这个项目并没有真正的支持Windows的风格,在cmd中使用SET命令设置的环境变量,git基本是无视的。

目录
相关文章
|
2天前
|
人工智能 缓存 开发工具
结合企业实践来规范你的Git commit(含插件使用指南)
结合企业实践来规范你的Git commit(含插件使用指南)
结合企业实践来规范你的Git commit(含插件使用指南)
|
1天前
|
JSON 开发工具 git
git rebase 合并当前分支的多个commit记录
git rebase 合并当前分支的多个commit记录
|
1天前
|
开发工具 git 开发者
掌握常见Git操作:技巧与实践
掌握常见Git操作:技巧与实践
|
2天前
|
开发工具 git
Git项目如何配置,如何上传至GitHub。其详细步骤
Git项目如何配置,如何上传至GitHub。其详细步骤
10 0
|
2天前
|
网络安全 数据安全/隐私保护
解决git@github.com: Permission denied (publickey). fatal: Could not read from remote repository. Pleas
解决git@github.com: Permission denied (publickey). fatal: Could not read from remote repository. Pleas
|
2天前
|
存储 开发工具 git
|
2天前
|
开发工具 git 开发者
【专栏】探讨了 Git 中的 `git rebase` 操作,它用于重新应用提交到另一分支,改变历史顺序
【4月更文挑战第29天】本文探讨了 Git 中的 `git rebase` 操作,它用于重新应用提交到另一分支,改变历史顺序。与 `git merge` 不同,rebase 重写提交历史,提供简洁线性的历史记录。文章介绍了 rebase 的基本操作、应用场景,如整理提交历史、解决冲突和整合分支,并强调了使用注意事项,如避免在公共分支上操作。尽管 rebase 可以带来整洁的历史和冲突解决便利,但其潜在的风险和可能导致的历史混乱需谨慎对待。理解并恰当使用 `git rebase` 可以提升开发效率和代码质量。
|
2天前
|
开发工具 数据安全/隐私保护 C++
vs2019中同步到github上的用户名错误_控制面板和vs的git全局设置重新登录
vs2019中同步到github上的用户名错误_控制面板和vs的git全局设置重新登录
17 0
|
2天前
|
前端开发 JavaScript 网络安全
Git(3) 使用Github管理项目
Git(3) 使用Github管理项目
26 0
|
2天前
|
Linux 开发工具 git
还不会 Git 子模块操作?一文教你学会 git submodule 的增、删、改、查!
还不会 Git 子模块操作?一文教你学会 git submodule 的增、删、改、查!

热门文章

最新文章