限制 git 存储库中的文件大小

Question

我目前正在考虑将我的 VCS（从 subversion）更改为 git。是否可以限制 git 存储库中提交的文件大小？对于例如颠覆，有一个钩子： http://www.davidgrant.ca/limit_size_of_subversion_commits_with_this_hook

根据我的经验，人们，尤其是那些缺乏经验，有时倾向于提交不应进入 VCS 的文件（例如大文件系统映像）。

Answer 1

由于我在这个问题上挣扎了一段时间，即使有描述，我认为这也与其他人相关，我想我应该发布一个如何实现J16 SDiZ 描述可以实现。

所以，我对服务器端的看法 update 钩子防止推送太大的文件：

#!/bin/bash

# Script to limit the size of a push to git repository.
# Git repo has issues with big pushes, and we shouldn't have a real need for those
#
# eis/02.02.2012

# --- Safety check, should not be run from command line
if [ -z "$GIT_DIR" ]; then
        echo "Don't run this script from the command line." >&2
        echo " (if you want, you could supply GIT_DIR then run" >&2
        echo "  $0 <ref> <oldrev> <newrev>)" >&2
        exit 1
fi

# Test that tab replacement works, issue in some Solaris envs at least
testvariable=`echo -e "\t" | sed 's/\s//'`
if [ "$testvariable" != "" ]; then
        echo "Environment check failed - please contact git hosting." >&2
        exit 1
fi


# File size limit is meant to be configured through 'hooks.filesizelimit' setting
filesizelimit=$(git config hooks.filesizelimit)

# If we haven't configured a file size limit, use default value of about 100M
if [ -z "$filesizelimit" ]; then
        filesizelimit=100000000
fi

# Reference to incoming checkin can be found at $3
refname=$3

# With this command, we can find information about the file coming in that has biggest size
# We also normalize the line for excess whitespace
biggest_checkin_normalized=$(git ls-tree --full-tree -r -l $refname | sort -k 4 -n -r | head -1 | sed 's/^ *//;s/ *$//;s/\s\{1,\}/ /g' )

# Based on that, we can find what we are interested about
filesize=`echo $biggest_checkin_normalized | cut -d ' ' -f4,4`

# Actual comparison
# To cancel a push, we exit with status code 1
# It is also a good idea to print out some info about the cause of rejection
if [ $filesize -gt $filesizelimit ]; then

        # To be more user-friendly, we also look up the name of the offending file
        filename=`echo $biggest_checkin_normalized | cut -d ' ' -f5,5`

        echo "Error: Too large push attempted." >&2
        echo  >&2
        echo "File size limit is $filesizelimit, and you tried to push file named $filename of size $filesize." >&2
        echo "Contact configuration team if you really need to do this." >&2
        exit 1
fi

exit 0

请注意，它已评论该代码仅检查最新的提交，因此需要调整该代码以迭代 $2 和 $3 之间的提交并执行检查所有的人。

Answer 2

eis 和 J-16 SDiZ 的答案存在严重问题。
他们只检查最终提交 $3 或 $newrev 的状态。
他们还需要检查其他提交中提交的内容
udpate 挂钩中的 $2（或 $oldrev）和 $3（或 $newrev）之间。

J-16 SDiZ 更接近正确答案。

最大的缺陷是，如果某个部门的服务器安装了这个更新挂钩来保护它，那么他会发现：

在使用 git rm 删除意外签入的大文件后，
那么当前树或最后一次提交就可以了，而且它会
拉入整个提交链，包括大文件
被删除，创造了一个没人想要的膨胀的、不愉快的肥胖历史。

解决方案是检查从 $oldrev 到 $newrev 的每个提交，或者指定整个范围 $oldrev..$newrev。
请确保您不仅仅是单独检查 $newrev，否则这将会失败
你的 git 历史记录中有大量垃圾，被推出与他人分享，
然后就很难或不可能去除。

Answer 3

这个非常好：

#!/bin/bash -u
#
# git-max-filesize
#
# git pre-receive hook to reject large files that should be commited
# via git-lfs (large file support) instead.
#
# Author: Christoph Hack <[email protected]>
# Copyright (c) 2017 mgIT GmbH. All rights reserved.
# Distributed under the Apache License. See LICENSE for details.
#
set -o pipefail

readonly DEFAULT_MAXSIZE="5242880" # 5MB
readonly CONFIG_NAME="hooks.maxfilesize"
readonly NULLSHA="0000000000000000000000000000000000000000"
readonly EXIT_SUCCESS="0"
readonly EXIT_FAILURE="1"

# main entry point
function main() {
  local status="$EXIT_SUCCESS"

  # get maximum filesize (from repository-specific config)
  local maxsize
  maxsize="$(get_maxsize)"
  if [[ "$?" != 0 ]]; then
    echo "failed to get ${CONFIG_NAME} from config"
    exit "$EXIT_FAILURE"
  fi

  # skip this hook entirely if maxsize is 0.
  if [[ "$maxsize" == 0 ]]; then
    cat > /dev/null
    exit "$EXIT_SUCCESS"
  fi

  # read lines from stdin (format: "<oldref> <newref> <refname>\n")
  local oldref
  local newref
  local refname
  while read oldref newref refname; do
    # skip branch deletions
    if [[ "$newref" == "$NULLSHA" ]]; then
      continue
    fi

    # find large objects
    # check all objects from $oldref (possible $NULLSHA) to $newref, but
    # skip all objects that have already been accepted (i.e. are referenced by
    # another branch or tag).
    local target
    if [[ "$oldref" == "$NULLSHA" ]]; then
      target="$newref"
    else
      target="${oldref}..${newref}"
    fi
    local large_files
    large_files="$(git rev-list --objects "$target" --not --branches=\* --tags=\* | \
      git cat-file 
你可以通过添加以下内容在服务器端 config 文件中配置大小：
[hooks]
        maxfilesize = 1048576 # 1 MiB

--batch-check=%(objectname)\t%(objecttype)\t%(objectsize)\t%(rest)' | \
      awk -F '\t' -v maxbytes="$maxsize" '$3 > maxbytes' | cut -f 4-)"
    if [[ "$?" != 0 ]]; then
      echo "failed to check for large files in ref ${refname}"
      continue
    fi

    IFS=
你可以通过添加以下内容在服务器端 config 文件中配置大小：

\n'
    for file in $large_files; do
      if [[ "$status" == 0 ]]; then
        echo ""
        echo "-------------------------------------------------------------------------"
        echo "Your push was rejected because it contains files larger than $(numfmt --to=iec "$maxsize")."
        echo "Please use https://git-lfs.github.com/ to store larger files."
        echo "-------------------------------------------------------------------------"
        echo ""
        echo "Offending files:"
        status="$EXIT_FAILURE"
      fi
      echo " - ${file} (ref: ${refname})"
    done
    unset IFS
  done

  exit "$status"
}

# get the maximum filesize configured for this repository or the default
# value if no specific option has been set. Suffixes like 5k, 5m, 5g, etc.
# can be used (see git config --int).
function get_maxsize() {
  local value;
  value="$(git config --int "$CONFIG_NAME")"
  if [[ "$?" != 0 ]] || [[ -z "$value" ]]; then
    echo "$DEFAULT_MAXSIZE"
    return "$EXIT_SUCCESS"
  fi
  echo "$value"
  return "$EXIT_SUCCESS"
}

main

你可以通过添加以下内容在服务器端 config 文件中配置大小：

Answer 4

如果您使用的是 gitolite，您也可以尝试 VREF。
默认情况下已经提供了一个 VREF（代码位于 gitolite/src/VREF/MAX_NEWBI_SIZE 中）。
它称为 MAX_NEWBI_SIZE。
它的工作原理如下：

repo name
RW+     =   username
-   VREF/MAX_NEWBIN_SIZE/1000   =   usernames 

其中 1000 是示例阈值（以字节为单位）。

此 VREF 的工作方式类似于更新挂钩，如果您要推送的一个文件大于阈值，它将拒绝您的推送。

Answer 5

是的，git 也有钩子（git 钩子） 。但这在某种程度上取决于您将使用的实际工作流程。

如果您的用户没有经验，那么先拉，然后让他们推会安全得多。这样，您可以确保他们不会搞砸主存储库。

Answer 6

我想强调另一组在拉取请求阶段解决此问题的方法：GitHub Actions 和 Apps。它不会阻止大文件被提交到分支中，但如果它们在合并之前被删除，那么生成的基础分支将不会在历史记录中包含大文件。

最近开发了一个操作，可以根据用户定义的参考值检查添加的文件大小（通过 GitHub API）：lfs-警告。

我还亲自编写了一个 Probot 应用程序来筛选 PR 中的大文件（针对用户定义的值），但效率低得多：

Answer 7

从我在某人签入时看到的情况来看，这将是非常罕见的情况，例如 200Mb 甚至更大大小的文件。

虽然您可以通过使用服务器端挂钩（不确定客户端挂钩，因为您必须依赖安装挂钩的人）来防止这种情况发生，就像在 SVN 中一样，但您还必须考虑到 Git 中的情况，从存储库中删除这样的文件/提交要容易得多。在 SVN 中你没有这样的奢侈，至少不是一个简单的方法。

Answer 8

我正在使用 gitolite 并且更新挂钩已经被使用 - 我没有使用更新挂钩，而是使用了预接收挂钩。 Chriki 发布的脚本工作得非常好，除了数据是通过 stdin 传递的 - 所以我做了一行更改：（

- refname=$3
+ read a b refname

可能有一种更优雅的方法来做到这一点，但它有效）

Answer 9

您需要一个能够满足以下场景的解决方案。

1. 如果有人将多个提交一起推送，则挂钩应该检查该推送中的所有提交（oldref 和 newref 之间）是否存在大于特定限制的文件。
2. 挂钩应该为所有用户运行。如果您编写客户端钩子，则它不会对所有用户可用，因为当您执行 git Push 时不会推送此类钩子。因此，需要一个服务器端钩子，例如预接收钩子。

这个钩子（https://github.com/mgit-at/git-max-filesize ）处理上述两种情况，并且似乎也可以正确处理边缘情况，例如新分支推送和分支删除。

Answer 10

另一种方法是对 .gitignore 进行版本控制，这将阻止任何具有特定扩展名的文件显示在状态中。
您仍然可以有挂钩（在下游或上游，如其他答案所建议的），但至少所有下游存储库都可以包含 .gitignore 以避免添加 .exe, .dll, .iso, ...

---

如果您使用钩子，请考虑 Git 2.42 (Q3 2023)：一些可用于“--format=” 为“git ls-tree“^(man) 不被 git ls-files^(man)，即使它们与后者的上下文相关。

请参阅 提交 4d28c4f（2023 年 5 月 23 日），作者：胡哲宁（adlternative）。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 32fe7ff，2023 年 6 月 13 日）}

ls-files：将格式原子与ls-树

^{签字人：胡哲宁}

"git ls-文件 --format"^{(man) 可用于格式化索引中多个文件条目的输出，而 "git ls-tree --format"(男人) 可用于格式化树对象的内容。
但是，“git ls-files --format”支持的当前 %(objecttype)、“(objectsize)”和“%(objectsize:pangled)”原子集是以下内容的子集：可用在 git ls-tree --format (man)"。}

用户有时需要在索引和树之间建立统一的视图，这有助于两者之间的比较或转换。

因此，此补丁将缺失的原子添加到“git ls-files"^(man) --format"。

• “%(objecttype)”可用于检索索引中某个文件对应的对象类型，
• “%(objectsize)”可用于检索索引中文件对应的对象大小，并且
• “%(objectsize:pangled)”与“%(objectsize)”相同，只是采用了填充格式。

git ls-files 现在包含在其 手册页：

对象类型

索引中记录的文件的对象类型。

git ls-files 现在包含在其 手册页：

对象大小[:填充]

索引中记录的文件的对象大小
（如果对象是提交或树，则为“-”）。
它还支持大小为“%(objectsize:pangled)”的填充格式。

Answer 11

您可以使用 钩子，或者 pre-commit 钩子（在客户端），或者一个update钩子（在服务器上）。执行 git ls-files --cached （用于预提交）或 git ls-tree --full-tree -r -l $3 （用于更新）并执行因此。

git ls-tree -l 会给出类似这样的结果：

100644 blob 97293e358a9870ac4ddf1daf44b10e10e8273d57    3301    file1
100644 blob 02937b0e158ff8d3895c6e93ebf0cbc37d81cac1     507    file2

抓住第四列，它就是大小。使用 git ls-tree --full-tree -r -l HEAD |排序-k 4 -n -r | head -1 获取最大的文件。 cut 提取，if [ a -lt b ] 检查大小等。

抱歉，我认为如果你是程序员，你应该能够自己做到这一点。