我们有一个存储库，我们在其中提交报告的PDF快照。我想试试git lfs，看看它是否能提高生活质量。
我按照这里的程序（https://github.com/rtyley/bfg-repo-cleaner/releases）使用BFG清理旧的二进制文件并转换为lfs。我通过一些与Gitlab服务器用于存储库相关的皱纹来解决问题，但最后我相信这很顺利。
我写信是为了展示我们做了什么，并提出了一个关于在最后清理合并冲突的问题。
我会告诉你成绩单。我们查看了一个“ - 镜像”克隆（一个简单的回购），然后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.
我想我可能只是做一个干净的克隆遥控器并从那里继续。我在互联网上找到的说明对此没什么帮助，它们主要是关于开始使用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框架，但我还没有成功导航它。在我看来，这让我陷入编辑地狱。
答案 0 :(得分：1)
我想我可能只是做一个干净的遥控器克隆并从那里继续。
是的，这是使用任何工具后最重要的一步，无论是BFG，filter-branch等，它都会重写历史记录（通常在这样做时会删除该历史记录中引用的不需要的文件）。 BFG主页说：
此时，你已经准备好让每个人都放弃他们旧的回购副本，并做出新的原始数据的新克隆。最好删除所有旧克隆，因为它们会有不想要冒回到新清理的仓库中的脏历史。
对于Git而言，新的/重写的历史将从历史前进的某个点（重写的第一个更改的点）与旧的历史完全不同，因为从那一点开始所有的提交哈希将改变。唯一明智的方法是让所有开发人员退出他们当前的旧历史克隆并获得新的克隆。理论上你可以更新这些，但它需要很多照顾而没有多大价值。
删除旧克隆可以减少某人推送旧历史记录的机会，从而重新引入旧历史记录及其中包含的不需要的文件。