git lfs bfg：在那之后，如何解决冲突？答案

【问题标题】：git lfs bfg: after that, resolve conflicts how?git lfs bfg：在那之后，如何解决冲突？
【发布时间】：2016-10-06 17:17:25
【问题描述】：

我们有一个存储库，我们在其中提交了报告的 PDF 快照。我想试试git lfs，看看它是否能提高生活质量。

我按照这里的程序 (https://github.com/rtyley/bfg-repo-cleaner/releases) 使用 BFG 清理旧的二进制文件并转换到 lfs。我克服了与将 Gitlab 服务器用于存储库相关的一些问题，但最终我相信这进展顺利。

我写信是为了展示我们所做的事情，并在最后询问有关清理合并冲突的问题。

我会给你看成绩单。我们检查了一个“--mirror”克隆（一个裸仓库），BFG 对此进行了工作，然后我们在摆弄之后将其推回：

guides-to-lfs$ git clone --mirror git@gitlab.kucenter.edu:crmda/guides.git
Cloning into bare repository 'guides.git'...
X11 forwarding request failed on channel 0
remote: Counting objects: 865, done.
remote: Compressing objects: 100% (527/527), done.
remote: Total 865 (delta 318), reused 834 (delta 303)
Receiving objects: 100% (865/865), 151.75 MiB | 25.74 MiB/s, done.
Resolving deltas: 100% (318/318), done.
Checking connectivity... done.

guides-to-lfs$ cd guides.git/

guides.git$ java -jar ~/bin/bfg-1.12.13.jar --convert-to-git-lfs '*.{pdf,ogv,tar.gz,zip}' --no-blob-protection

Using repo : /home/pauljohn/GIT/CRMDA/guides-to-lfs/guides.git

Found 0 objects to protect
Found 3 commit-pointing refs : HEAD, refs/heads/master, refs/tmp/fd782dd8787a3ffb673455d1eafb9869/head

Protected commits
-----------------

You're not protecting any commits, which means the BFG will modify the contents of even *current* commits.

This isn't recommended - ideally, if your current commits are dirty, you should fix up your working copy and commit that, check that your build still works, and only then run the BFG to clean up your history.

Cleaning
--------

Found 124 commits
Cleaning commits:       100% (124/124)
Cleaning commits completed in 1,933 ms.

Updating 2 Refs
---------------

    Ref                                              Before     After   
    --------------------------------------------------------------------
    refs/heads/master                              | e3327ef1 | e4ac76a2
    refs/tmp/fd782dd8787a3ffb673455d1eafb9869/head | 74ccc454 | 6639b246

Updating references:    100% (2/2)
...Ref update completed in 19 ms.

Commit Tree-Dirt History
------------------------

    Earliest                                              Latest
    |                                                          |
    .......DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

    D = dirty commits (file tree fixed)
    m = modified commits (commit message or parents changed)
    . = clean commits (no changes to file tree)

                            Before     After   
    -------------------------------------------
    First modified commit | cdd8f486 | 5e6b64eb
    Last dirty commit     | e3327ef1 | e4ac76a2

Changed files
-------------

    Filename                                               Before & After                                               
    --------------------------------------------------------------------------------------------------------------------
    01.LISREL.Syntax.pdf                                 | 71a17dcc ⇒ 7f217f4d                                          
    02.ReadingDataIntoLISREL.pdf                         | c05c3fe6 ⇒ e7238e11                                          
    03.InterpretingLISRELOutput.pdf                      | 6ef054c8 ⇒ a2a63813                                          
    04.StartingValuesInLISREL.pdf                        | 335d7a09 ⇒ c86439ee, 9f6fc232 ⇒ 05182a86                     
    05.WhatToReport.pdf                                  | 2bee7a8d ⇒ 1106d2f4, 3d30b103 ⇒ ce27382c                     
    06.Satorra-BentlerChi-Sq.pdf                         | 94ec6fd2 ⇒ b81d08b4, 7cd29d48 ⇒ 704d5f30                     
    ...

In total, 375 object ids were changed. Full details are logged here:

guides.git.bfg-report/2016-10-05/14-03-18

BFG run is complete! When ready, run: git reflog expire --expire=now --all && git gc --prune=now --aggressive

guides.git$ git reflog expire --expire=now --all

guides.git$ git gc --prune=now

如果你尝试这个，你应该准备好迎接一些麻烦回到回购。一个问题是 8.12 之前的 Gitlab 没有在 git 的 SSH 传输和 git lfs 的 HTTPS 传输之间集成密码管理。另一个问题是 Gitlab 项目的“保护”，如果你使用 Gitlab，你可能已经看到了。我第一次推送时就看到了：

guides.git$ git push
X11 forwarding request failed on channel 0
Git LFS: (0 of 105 files) 0 B / 140.38MB                          
http: Post https://gitlab.kucenter.edu/crmda/guides.git/info/lfs/objects/batch: x509: certificate signed by unknown authority
http: Post https://gitlab.kucenter.edu/crmda/guides.git/info/lfs/objects/batch: x509: certificate signed by unknown authority
error: failed to push some refs to 'git@gitlab.kucenter.edu:crmda/guides.git'

我们进行了一些更改来解决这个问题。我们需要绝对最新版本的 Gitlab (8.12.4)。我需要告诉 Git 忽略过期的证书。在 Gitlab 服务器上，项目必须“不受保护”，以便开发人员可以推送。我不明白为什么这是必要的，因为我是所有者，我可以推送定期的 git 更改，但显然 lfs 集成是不同的。经过一番折腾，我们成功推回了仓库：

guides.git$ GIT_SSL_NO_VERIFY=true git push
X11 forwarding request failed on channel 0
Git LFS: (0 of 0 files, 105 skipped) 0 B / 0 B, 140.38 MB skipped                                                                   Counting objects: 866, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (520/520), done.
Writing objects: 100% (866/866), 32.94 MiB | 26.41 MiB/s, done.
Total 866 (delta 311), reused 866 (delta 311)
To git@gitlab.kucenter.edu:crmda/guides.git
 + e3327ef...e4ac76a master -> master (forced update)
 + 74ccc45...6639b24 refs/tmp/fd782dd8787a3ffb673455d1eafb9869/head -> refs/tmp/fd782dd8787a3ffb673455d1eafb9869/head (forced update)

成功了！

然后我回到这个存储库的工作目录，其中保存了 PDF 文件，并尝试了 git pull。我看到了很多我必须解决的合并冲突：

guides$ git pull
X11 forwarding request failed on channel 0
remote: Counting objects: 792, done.
remote: Compressing objects: 100% (491/491), done.
remote: Total 792 (delta 294), reused 791 (delta 293)
Receiving objects: 100% (792/792), 32.92 MiB | 54.09 MiB/s, done.
Resolving deltas: 100% (294/294), done.
From gitlab.kucenter.edu:crmda/guides
 + e3327ef...e4ac76a master     -> origin/master  (forced update)
warning: Cannot merge binary files: keyword_guide/guide_keywords.pdf (HEAD vs. e4ac76a2561fd4dc3ca52971e8ee3d5cbe930a0c)
warning: Cannot merge binary files: Spanish_KUant_Guides/PDFs/9._opcion_RP_en_LISREL.pdf (HEAD vs. e4ac76a2561fd4dc3ca52971e8ee3d5cbe930a0c)
warning: Cannot merge binary files: Spanish_KUant_Guides/PDFs/8._Imputacion_de_datos.pdf (HEAD vs. e4ac76a2561fd4dc3ca52971e8ee3d5cbe930a0c)
warning: Cannot merge binary files: Spanish_KUant_Guides/PDFs/7._bootstrap.pdf (HEAD vs. e4ac76a2561fd4dc3ca52971e8ee3d5cbe930a0c)
warning: Cannot merge binary files: Spanish_KUant_Guides/PDFs
[...snip out hundreds of those ...]
Automatic merge failed; fix conflicts and then commit the result.

我认为我可能只是对遥控器进行干净的克隆，然后从那里继续。我在 Internet 上找到的说明对此没有太大帮助，它们主要是关于 lfs 的入门，而不是关于处理正在进行的 lfs 和 lfs 的克隆。我有点担心如果有人克隆了这个东西而他们没有 lfs 会发生什么。哦，好吧，我们拭目以待。

这是我的问题。如果我确实想处理所有这些二元冲突，我会怎么做？如果我只是想接受来自服务器的所有更改，看来我只需要一遍又一遍地运行它，为每个冲突的“fn.pdf”运行一次。

$ git checkout --theirs -- fn.pdf
$ git add fn.pdf

一遍又一遍地这样做似乎很乏味，但我想我可以做到。

我也在这里找到了建议 (Resolving a Git conflict with binary files) 尝试

$ git mergetool

但我无法确定如何与之交互。 diff 东西启动了一个带有 3 列缓冲区的 gvim 框架，但我没有成功导航它。在我看来，这让我陷入了编辑地狱。

【问题讨论】：

我又发现了一个问题。我的“.gitattributes”文件如下所示：“*.{pdf,ogv,tar.gz,zip} filter=lfs diff=lfs merge=lfs -text” 据称在 2015 bfg 页面 (github.com/rtyley/bfg-repo-cleaner/issues/116)这是错误的，它不应该那样使用 glob，它应该是每个元素一行。我正在检查是否仍然如此。如果这是真的，我应该为每个文件扩展名运行一次 bfg，而不是执行 {pdf,gz} 之类的。这个“错误”似乎不太可能一直保持未修复。
是的，虽然 #156 已合并，但通配功能的不匹配仍然存在，因此命令行帮助不再提倡这种方法。
你能完成一个新的克隆吗？
是的，我可以克隆。已验证如果我在启用 git-lfs 的系统中克隆，我确实得到了二进制文件。如果我们从另一个没有 lfs 的系统克隆，我们会得到引用。我检查了你的答案是正确的。

标签： git version-control git-lfs bfg-repo-cleaner

【解决方案1】：

我想我可能会简单地克隆遥控器并从那里继续。

是的，这是使用任何工具（无论是 BFG、filter-branch 等）重写历史记录后最重要的一步（通常这样做是删除该历史记录中引用的不需要的文件）。 BFG主页说：

此时，您已准备好让每个人都放弃旧的 repo 副本，并对漂亮的新原始数据进行新的克隆。最好删除所有旧克隆，因为它们会有脏历史，您不想冒着推回新清理的存储库的风险。

就 Git 而言，新/重写的历史将来自历史中的某个点（重写中第一次更改的点）与旧历史完全不同，因为从该点开始的所有提交哈希将改变。唯一明智的做法是让所有开发人员退出他们当前对旧历史的克隆并获得新的克隆。理论上您可以更新这些内容，但需要非常小心，但价值不大。

删除旧克隆可减少有人推送对旧历史记录的引用的机会，从而重新引入旧历史记录及其包含的不需要的文件。

【讨论】：