git VS git-lfs

Compare git vs git-lfs and see what are their differences.


A fork of Git containing Windows-specific patches. (by git-for-windows)


Git extension for versioning large files (by git-lfs)
Our great sponsors
  • InfluxDB - Collect and Analyze Billions of Data Points in Real Time
  • Onboard AI - Learn any GitHub repo in 59 seconds
  • SaaSHub - Software Alternatives and Reviews
git git-lfs
614 153
7,872 12,031
0.5% 0.9%
9.9 9.0
9 days ago 4 days ago
C Go
GNU General Public License v3.0 or later GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of git. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-09-19.
  • An AsyncAPI Example: Building Your First Event-driven API
    6 projects | | 19 Sep 2023
  • Basics of Git
    2 projects | | 17 Sep 2023
    Before you start using Git, you need to install it on your computer. You can download and install Git from the official website ( Once installed, open a terminal or command prompt and run the following commands to configure Git with your name and email:
  • Publish an NPM Package from a GitHub Repository
    2 projects | | 13 Sep 2023
    Git: You should have Git installed on your machine. You can download it from the official website (
  • Better Git Commits with `@commitlint`
    2 projects | | 11 Sep 2023
    When working on a project together, Git is a crucial tool that help teams collaborate smoothly. One of the key features is commits, which act like snapshots of the project's progress.
  • "Мобильная" разработка. [Системы контроля версий, Git]
    5 projects | | 8 Sep 2023
    Официальный сайт Git
  • Running an Arweave Gateway in the Dark Web
    4 projects | | 4 Sep 2023
    You need Git, Docker, and a browser that's able to handle .onion addresses (e.g., Tor Browser or Brave).
  • Unix sockets, Cygwin, SSH agents, and sadness
    4 projects | | 29 Aug 2023
    > Git for Windows is built on top of msys2, which in turn is built on top of Cygwin.

    you can get native Windows Git as well. its called MinGit:

  • pyaction 4.22.0 Released
    4 projects | | 28 Aug 2023
    This Docker image is designed to support implementing Github Actions with Python. As of version 4.0.0., it starts with the official python docker image as the base which is a Debian OS. It specifically uses python:3-slim to keep the image size down for faster loading of Github Actions that use pyaction. On top of the base, we've installed curl gpg, git, and the GitHub CLI. We added curl and gpg because they are needed to install the GitHub CLI, and they may come in handy anyway (especially curl) when implementing a GitHub Action.
  • Fortran
    4 projects | | 28 Aug 2023
    > I didn’t intend to say that «not official» means «bad».

    Yes, I know, I understood that. Thank you. I was reacting to the term official, since it is an interesting question what official means for Fortran, since in a way it was "abandoned", there was the ISO committee as the only official body, but nobody wanted to provide an official place for it on the internet. So we volunteered that. In a way, I think it could already be treated as official, or if not, hopefully in a few years most people will treat it as the de-facto official. Kind of like the git webpage has migrated from to, but both in a way are unofficial, but the second one is a nice modern webpage and most people liked it and accepted it as official. I don't know the people behind either webpage.

  • Understanding Git and GitHub
    2 projects | | 20 Aug 2023
    Git can be directly installed from this website. (


Posts with mentions or reviews of git-lfs. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-08-28.
  • We Put Half a Million Files in One Git Repository, Here's What We Learned (2022)
    4 projects | | 28 Aug 2023
  • Show HN: Gogit – Just enough Git (in Go) to push itself to GitHub
    8 projects | | 29 Jul 2023
    I don’t know what that is, but their docs very prominently and strongly say this:

    > However, we do not maintain a stable Go language API or ABI, as Git LFS is intended to be used solely as a compiled binary utility. Please do not import the git-lfs module into other Go code and do not rely on it as a source code dependency.

    8 projects | | 29 Jul 2023
    > I don’t know what that is

    its a standard output from `go doc`, rendered as HTML. if you dont recognize that, then you aren't really in a position to be commenting on the topic. nothing is stopping anyone from pinning to a tag:

    or even a commit and relying of a specific version of the software. yes upgrades might be painful but a module IS available.

  • Unable to push because of large file deleted in the past
    2 projects | /r/git | 3 Jul 2023
    # git push origin feature-branch /usr/bin/gh auth git-credential get: 1: /usr/bin/gh auth git-credential get: /usr/bin/gh: not found /usr/bin/gh auth git-credential store: 1: /usr/bin/gh auth git-credential store: /usr/bin/gh: not found Enumerating objects: 9228, done. Counting objects: 100% (7495/7495), done. Delta compression using up to 8 threads Compressing objects: 100% (2090/2090), done. Writing objects: 100% (6033/6033), 72.77 MiB | 7.39 MiB/s, done. Total 6033 (delta 4402), reused 5194 (delta 3616) remote: Resolving deltas: 100% (4402/4402), completed with 477 local objects. remote: error: Trace: c1c90b47a5483929dcdd8c974a6c7d0695e86f67f680d8b88b80ef1c1bce74a remote: error: See for more information. remote: error: File deployment_20200220.sql is 872.78 MB; this exceeds GitHub's file size limit of 100.00 MB remote: error: GH001: Large files detected. You may want to try Git Large File Storage - To ! [remote rejected] rest-logging -> rest-logging (pre-receive hook declined) error: failed to push some refs to ''
  • What and Why, Git LFS?
    3 projects | | 12 Jun 2023
  • Coding your own AI in 2023 with fastai
    3 projects | | 27 Feb 2023
    Before commit we need to install git-lfs first, because our model.pkl file is too big. Follow the link and the instructions to install it for your operating system. Now we are able to use git-lfs for our model.pkl:
  • Golang is evil on shitty networks
    2 projects | /r/programming | 29 Dec 2022
    git-lfs issue
    21 projects | | 29 Dec 2022
    > And that pattern is the one that is used by GOs http libraries

    I don't think that is correct. In, I notice that Go's HTTP/2 library would write the HEADERS frame, the DATA frame, and the terminal HEADERS frame in 3 different syscalls. In a sample application using the Go's HTTP/2 library, a gRPC response without Nagle's algorithm would transmit 497 bytes over 6 packets, while a gRPC response with Nagle's algorithm would transmit 275 bytes over 2 packets.

    With a starting point where both Nagle's algorithm and delayed ack are enabled, I guess this is the order of preference:

    1. delayed ack disabled, applications do the right thing by buffering accordingly - ideal performance, but it is difficult to disable delayed ack, and it may require a lot of works to fix the applications.

    2a. Nagle's algorithm disabled, applications do the right thing by buffering accordingly - almost ideal performance (may perform worse than #1 over bad connection), but it may require a lot of works to fix the applications.

    2b. delayed ack disabled, real world applications - almost ideal performance (may have higher syscall overhead than #1), but it is difficult to disable delayed ack.

    3. Nagle's algorithm disabled, real world application - not ideal as some applications can suffer from high packet overhead, e.g. git-lfs, and this is where we are at with Go.

    4. baseline - far from ideal as many applications can suffer from high latency due to bad interaction between Nagle's algorithm and delayed ack.

    I would say Go has made the right trade-off, albeit with a slight hint of "we know better than you". Going forward, it is probably cheaper for linux kernel to come up with a better API to disable delayed ack (i.e. to achieve #2b), than getting the affected applications to do the right thing by buffering accordingly (i.e. to achieve #1 or #2a). We will see how soon can be resolved.

    In the mean time, #2b can actually be achieved with a "SRE approach" by patching the kernel to remove delayed ack and patching the Go library to remove the `setNoDelay` call. Something for OP to try?

    21 projects | | 29 Dec 2022
    git-lfs authors agree and point out regular git also disables Nagle.

    21 projects | | 29 Dec 2022
    > I will just add that it makes no sense at all that git-lfs (lf = large file!) should be sending large files 50 bytes at a time. That's a huge number of system calls that could be avoided by doing larger writes. And then the larger writes would work better for the TCP stack anyway.

    FWIW, at least one git-lfs contributor agrees with you:

    > I think the first thing we should probably look at here is whether Git LFS (and the underlying Go libraries) are optimizing TCP socket writes or not. We should be avoiding making too many small writes where we can instead make a single larger one, and avoiding the "write-write-read" pattern if it appears anywhere in our code, so we don't have reads waiting on the final write in a sequence of writes. Regardless of the setting of TCP_NODELAY, any such changes should be a net benefit.

What are some alternatives?

When comparing git and git-lfs you can also consider the following projects:

onedrive - OneDrive Client for Linux

git-fat - Simple way to handle fat files without committing them to git, supports synchronization using rsync

Gitea - Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD

Chocolatey - Chocolatey - the package manager for Windows


HomeBrew - 🍺 The missing package manager for macOS (or Linux)

scalar - Scalar: A set of tools and extensions for Git to allow very large monorepos to run on Git without a virtualization layer

nixpkgs - Nix Packages collection & NixOS

Bazel - a fast, scalable, multi-language and extensible build system

Camunda BPM - Flexible framework for workflow and decision automation with BPMN and DMN. Integration with Quarkus, Spring, Spring Boot, CDI.

gitignore - A collection of useful .gitignore templates

sensible-side-buttons - A macOS menu bar app that enables system-wide navigation functionality for the side buttons on third-party mice.