5

一位开发人员设法提交了一些未来日期的代码——确切地说是 2013 年 3 月 1 日

git show --format=fuller <SHA>

AuthorDate: Fri Mar 1 17:28:26 2013 +0300
CommitDate: Fri Mar 1 17:29:38 2013 +0300

这是 (a) 误导性的，并且 (b) 阻止 Jira 查找标有 Jira 票号的“新”提交（自 2013 年 3 月 1 日以来没有提交 - 并且不会持续 6 个月）

我找到了如何使用git filter-branch更正日期的示例，例如 http://git.661346.n2.nabble.com/date-change-of-commit-td3887606.html：

git filter-branch --env-filter ' 
  if [ $GIT_COMMIT = <sha1> ]; then 
    export GIT_AUTHOR_DATE="1112911993 -0700" 
    export GIT_COMMITTER_DATE="1112911993 -0700" 
  fi 
'

但它们伴随着可怕后果的警告。对以下任何一个或多个问题的回答将不胜感激。

  • 使用上述方法更改提交日期是什么体验？
  • 使用存储库的其他人有什么后果？
  • 主分支的突出特性或部署分支会产生什么后果？
  • 有没有更好的方法来做到这一点？
4

2 回答 2

2

任何给定提交的 sha1 都基于与该提交相关的所有信息，包括日期和之前所有提交的历史记录，直至项目开始。这使得有人无法在没有所有人注意的情况下恶意更改存储库。它还使得有人无法在没有每个人都注意到的情况下仁慈地更改存储库。

执行过滤器分支实质上会删除分支，直到错误提交之前的提交，并从该点开始创建一个全新的分支。如果在那之后创建了任何分支，则必须重新设置它的基础。如果从那时起有人拉，他们将不得不进行强制拉。不，没有其他破坏性的方法可以解决它，除了可能在 3 月之前破解 Jira 做你想做的事。

于 2012-09-10T19:08:30.440 回答
0

后果并没有那么可怕。很简单，任何使用错误提交拉取该分支的人可能需要在推送修复后采取额外的步骤，因为您将替换那里的提交，而不是之后放置额外的提交。

更具体地说，在您修复分支后，其他已拉取错误提交的用户将无法对分支进行简单的“快进”更新。不过，对于任何相对熟悉 git 的人来说，用 agit rebase或任何他们需要的东西来解决差异应该是一件容易的事。

于 2012-09-10T19:05:47.640 回答