51

我们有一个包含大约 500,000 行代码的项目,使用 git 进行管理,其中大部分是几年前的。我们即将进行一系列修改,以使旧代码符合开发人员社区的当前标准和最佳实践,涉及命名约定、异常处理、缩进等。

您可以将其视为介于漂亮打印和低级/机械重构之间的东西。

这个过程很可能会触及代码库中的几乎每一行代码(~85%),有些行会受到多达五次的修改。所有更改都旨在在语义上保持中立。

  • 有什么方法可以使更改对 git blame 等透明,以便在一个月后查看代码时,我们会看到引入了逻辑的提交,而不是更改缩进或大写的那个?
  • 从未经历此过程的分叉中提取合并的最佳方法是什么?我目前的计划是让一个脚本克隆分叉的 repo,将自动化过程应用于它及其基础,对它们进行比较,然后应用差异。但我希望有一个更清晰的答案。
  • 是否还有其他我没有看到的此类问题,如果有,可以采取哪些措施来缓解这些问题?我认为 git bisect 等应该没问题,git log 等跨越鸿沟会很烦人,除非你小心,而且 git diff 将是无望的,但我不相信我没有忽视另一个痛点。

  • 4

    4 回答 4

    27

    我不知道如何最好地处理你所描述的一些更具侵入性的变化,但是......

    ,和其他-w选项git blamegit diff导致 git 忽略空格的变化,因此您可以更轻松地看到真正的差异。

    于 2009-12-01T06:57:52.863 回答
    13

    我建议在一个中央 Git 存储库中一次一步地进行这些演变(中央作为“所有其他存储库的公共参考”):

    • 缩进
    • 然后重新排序方法
    • 然后重命名
    • 然后 ...

    但不是“缩进-重新排序-重命名-...-一个巨大的提交”。

    这样,你给 Git 一个合理的机会来跟踪重构修改中的变化。

    另外,我不会接受在推送代码之前没有应用相同重构的任何新合并(从其他 repo 中提取)。
    如果应用格式化过程对获取的代码带来任何更改,您可以拒绝它并要求远程仓库首先符合新标准(至少在进行任何推送之前从您的仓库中提取)。

    于 2009-12-01T07:14:45.340 回答
    10

    您还需要一个允许积极忽略空白的合并工具。p4merge 可以做到这一点,并且可以免费下载。

    于 2009-12-01T09:34:13.380 回答
    0

    这个问题有一个很好的解决方案。简要使用git filter-branch.

    我为自己使用了这段代码:

    git filter-branch --tree-filter "git diff-tree --name-only --diff-filter=AM -r --no-commit-id \$GIT_COMMIT | grep '.*cpp\|.*h' | xargs ./emacs-script" HEAD

    ./emacs-script是我使用 emacs 编写的用于更改代码样式的脚本,它只是调用indent-region每个文件。

    如果没有从存储库中删除或删除的任何文件,则此代码可以正常工作,在这种情况下使用--ignore-unmatch可能会有所帮助,但我不确定。

    于 2015-10-02T05:38:27.147 回答