This creates some unexpected behavior issues, limiting which Git commands are possible. These clones truncate the commit history to reduce the clone size.
git clone -depth=1 creates a shallow clone. These clones are best for build environments where the repository will be deleted after a single build, but you still need access to commit history. These clones download all reachable commits while fetching trees and blobs on-demand. git clone -filter=tree:0 creates a treeless clone. These clones are best for developers and build environments that span multiple builds. These clones download all reachable commits and trees while fetching blobs on-demand. git clone -filter=blob:none creates a blobless clone. There are three ways to reduce clone sizes for repositories hosted by GitHub. I presented some of these ideas and other helpful tips at GitHub Universe in my talk, Optimize your monorepo experience. If you are working with an extremely large monorepo, then these tradeoffs are more likely to be worthwhile or even necessary to interact with Git at that scale!īefore digging in on this topic, be sure you are familiar with how Git stores your data, including commits, trees, and blob objects. 
Each option breaks at least one expectation from the normal distributed nature of Git, and you might not be willing to make those tradeoffs. What if there was a better way? Could you get started working in the repository without downloading every version of every file in the entire Git history? Git’s partial clone and shallow clone features are options that can help here, but they come with their own tradeoffs. This is only fully realizable if you have all reachable data in your local repository. This means that you can work on your machine without needing a connection to a central server that controls how you interact with the repository. Git is designed as a distributed version control system. As your Git repositories grow, it becomes harder and harder for new developers to clone and start working on them.
0 kommentar(er)
