Large repository management
When code repositories are large or network connections are unstable, pushing and pulling can be time-consuming and may cause timeouts. Codeup supports Git Large File Storage (LFS), partial clone, and shallow clone to reduce local disk usage, speed up repository operations, and improve efficiency for large repositories.
Git LFS
Scenarios
Git-LFS is highly recommended for code repositories with the following characteristics:
Rapid repository size increase due to non-text files committed to a code repository
In some scenarios, you must commit non-text files such as art resources, algorithm models, and compilation artifacts to your code repository. Binary files are larger, harder to compress, and Git stores every historical version of them, causing rapid repository size growth. Cloning such a repository downloads all historical versions of all files, which significantly increases cloning time.
Git LFS lets you manage files by extension and skip downloading their historical versions during cloning, significantly reducing both the data volume and time required.
Usage notes
For more information, see the following topics:
Shallow clone scenarios: application building
Application building typically requires only the latest code, not the full history. Shallow clone truncates historical data and downloads only commits within a specified depth, significantly reducing pull time. For more information about how to use shallow clone, see git clone help documentation.
Partial clone scenarios
Partial clone allows you to clone a repository without downloading all objects upfront. Unlike shallow clone, partial clone retains the full commit history. Missing objects are automatically downloaded as needed. You can use partial clone in the following scenarios:
Large repository size
Even without binary files, repository size gradually increases with continuous commits, leading to longer cloning times. Since developers typically work with the latest code and rarely need historical data, partial clone filters out historical object data during cloning and downloads it on demand.
Monorepo for microservices
In monorepo mode, all code is stored in a single large repository, as commonly used in Android development. Partial clone combined with sparse checkout enables team members to download only the code they need instead of the entire repository.
For more information about partial clone, see Partial clone.
Summary
These features are not limited to the scenarios described above and can be combined based on your requirements:
-
Git LFS is suitable when repository size grows rapidly due to binary files. If your repository exceeds the Git capacity threshold, you must move binary files to Git LFS.
-
Shallow clone is suitable when you need to clone a repository to a specified depth without the full history, especially to accelerate builds.
-
Partial clone retains commit history and lets you download objects by type or directory using sparse checkout. Missing objects are downloaded automatically as needed.
If you have any questions, submit a ticket to contact technical support, or join the Alibaba Cloud DevOps code domain DingTalk group (ID: 32027065) for feedback and consultation. For more video explanations, see: Two common causes of Git repository expansion and solutions.