Question

我在Git中有一个XML模型（100 MB），它经常变化并且变大。我正在考虑使用Git LFS来处理它。

通过检查文档，我不确定Git LFS是否支持文件的实际合并，或者当出现冲突时，应遵循“我们的”或“他们的”方法。

Git LFS是否支持实际合并跟踪文件的“真实”内容？

----更新1 ----

我在计算机上安装了Git LFS，以跟踪.xml文件。因此，我的XML模型的内容不再是XML内容，而是指向Git LFS服务器的指针。以下是我的XML文件现在的样子。

 version https://git-lfs.github.com/spec/v1
 oid sha256:0e23dcebda1977c424e5d0f25fda57d6eff9c2a5bbb6df7dd4985b64cf437d20
 size 53

因此，如果我在两个分支中更改此XML文件并尝试合并，则会引发冲突。当我打开XML文件来解决冲突时，我需要在一个oid和另一个之间做出选择：

<<<<<<< HEAD
oid sha256:0e23dcebda1977c424e5d0f25fda57d6eff9c2a5bbb6df7dd4985b64cf437d20
size 53
=======
oid sha256:cbe18ff9b73fad7d5b9cdcd177f9be9cf25bc88db279f3136aed5bfdec7eb0f7
size 91554569
>>>>>>> refs/heads/LFSbr1

----更新2 ---

这是我在执行“git lfs env”时得到的：

WARNING: Reading LFS config from ".gitconfig", not ".lfsconfig". Rename to    ".lfsconfig" before Git LFS v2.0 to remove this warning.
git-lfs/1.3.1 (GitHub; darwin amd64; go 1.6.3; git 9c9dffb)
git version 2.9.0

LocalWorkingDir=
LocalGitDir=
LocalGitStorageDir=
LocalMediaDir=lfs/objects
LocalReferenceDir=
TempDir=lfs/tmp
ConcurrentTransfers=3
TusTransfers=false
BasicTransfersOnly=false
BatchTransfer=true
SkipDownloadErrors=false
FetchRecentAlways=false
FetchRecentRefsDays=7
FetchRecentCommitsDays=0
FetchRecentRefsIncludeRemotes=true
PruneOffsetDays=3
PruneVerifyRemoteAlways=false
PruneRemoteName=origin
AccessDownload=none
AccessUpload=none
DownloadTransfers=basic
UploadTransfers=basic
git config filter.lfs.smudge = "git-lfs smudge -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"

有什么问题吗？

Answer 1

是的，确实如此。在LFS内容和非LFS内容之间没有与合并操作相关的差异。 Git将管理合并，而不是Git LFS。

我认为“git lfs env”中缺少以下行：

git config filter.lfs.process = "git-lfs filter-process"

确保$ HOME / .gitconfig包含以下行：

[filter "lfs"]
    clean = git-lfs clean -- %f
    smudge = git-lfs smudge -- %f
    process = git-lfs filter-process
    required = true

Answer 2

据我所知，Git LFS用于二进制内容（图像，PDF）或大型生成的文件（zip，已编译文件）。如果XML文件是由某些进程生成的，则运行XML文件时应使用最新数据重建文件。否则，如果这些文件是由多个用户制作和修改的，我认为您必须将它们作为代码进行跟踪，才能解决合并冲突。

如何合并Git LFS跟踪的文件内容

2 个答案: