The previous chapter, Customizing and Extending Git, explained among others how to use Git hooks for automation moved earlier in the chapter. The client-side hooks were described in detail, while the server-side hooks were only sketched. Here, in this chapter, we will present the server-side hooks comprehensively, and mention the client-side hooks' usage as helpers.
The earlier chapters helped master your work with Git as a developer, as a person collaborating with others, and as a maintainer. When the book was talking about setting up repositories and branch structure, it was from the point of view of a Git user.
This chapter is intended to help readers who are in a situation of having to take up the administrative side of Git. This includes setting up remote Git repositories and configuring their access. It covers the work required to make Git go smoothly (that is, Git maintenance), and finding and recovering from the repository errors. This chapter will also describe transfer protocols and how to use server-side hooks for implementing and enforcing development policy. Additionally, you will find here a short description of the various types of tools that can be used to manage remote repositories, to help you choose among them.
In this chapter, we will cover the following topics:
- Server-side hooks—implementing a policy and notifications
- Transport protocols, authentication and authorization
- How to set up Git on the server
- Third-party tools for management of remote repositories
- Signed pushes to assert updating refs and enable audits
- Reducing the size of hosted repositories with alternates and namespaces
- Improving server performance and helping the initial clone
- Checking for repository corruption and fixing the repository
- Recovering from errors with the help of reflogs and
git fsck - Git repository maintenance and repacking
- Augmenting development workflows with Git
Occasionally, you may need to do some clean up of a repository, usually to make it more compact. Such clean ups are a very important step after migrating a repository from another version control system.
Modern Git (or rather all but ancient Git) from time to time runs the git gc --auto command in each repository. This command checks whether there are too many loose objects (objects stored as separate files, one file per object, rather than stored together in a packfile; objects are almost always created as loose), and if these conditions are met, then it would launch the garbage collection operation. The garbage collection means to gather up all the loose objects and place them in packfiles, and to consolidate many small packfiles into one large packfile. Additionally, it packs references into the packed-refs file. Objects that are unreachable even via reflog, and are safely old, do not get picked in the repack. Git would then delete loose objects and packfiles that got repacked (with some safety margin with respect to the age of the loose object's files), thus pruning old unreachable objects. There are various configuration knobs in the gc.* namespace to control garbage collection operations.
You can run auto gc manually with git gc --auto, or force garbage collection with git gc. The git count-objects command (perhaps with the help of the -v parameter) can be used to check whether there are signs that repack is needed. You can even run individual steps of the garbage collection individually with git repack, git pack-refs, git prune, and git prune-packed.
By default, Git would try to reuse the results of the earlier packing to reduce CPU time spent on the repacking, while still providing good disk space utilization. In some cases, you would want to more aggressively optimize the size of repository at the cost of it taking more time: this is possible with git gc --aggressive (or with repacking the repository by hand with git repack, run with appropriate parameters). It is recommended to do this after import from other version control systems; the mechanism that Git uses for importing (fast-import stream) is optimized for the speed of the operation, not for the final repository size.
There are issues of maintenance not covered by git gc, because of their nature. One of them is pruning (deleting) remote-tracking branches that got deleted in the remote repository. This can be done with git fetch --prune or git remote prune, or on a per-branch basis with git branch --delete --remotes <remote-tracking branch>. This action is left to the user, and not run by git gc, because Git simply cannot know whether you have based your own work on the remote-tracking branch that is to be pruned.