GIT Tutorial: Directory Structure
GIT Directory structure
A .git directory has a structure similar to the following one:
A deprecated way to store shorthands that specify URL to the git fetch, git pull and git push commands is to store a file in branches/<name> and give the name to the command in the place of the repository argument.
This is the last commit message. It’s not actually used by Git at all, but it is for your reference after you have made a commit. user@user:/GIT/test# cat COMMIT_EDITMSG first commit
This is the main Git configuration file. It keeps specific Git options for your project, such as your remotes, push configurations, tracking branches and more. Your configuration will be loaded first from this file, then from a ~/.gitconfig file and then from an /etc/gitconfig file, if they exist. A exemplary content of this file is: user@user:/GIT/test# cat config [core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true [remote "origin"] url = email@example.com:user/test.git fetch = +refs/heads/*:refs/remotes/origin/*
If you’re using gitweb or invoking git instaweb, this will show when you have viewed your repository or the list of all versioned repositories.
A folder with the GIT web scripts. They allow you to browse the git repository using a web browser.
This file holds a reference to the branch you are currently on. This tells Git what to use as the parent of your next commit: user@user:/GIT/test# cat HEAD ref: refs/heads/master
This directory contains shell scripts that are invoked after the corresponding Git commands. For example, after you run a commit, Git will try to execute the post-commit script.
The Git index is used as a staging area between your working directory and your repository. You can use the index to build up a set of changes that you want to commit together. When you create a commit, what is committed is what is currently in the index, not what is in your working directory. It is a binary file containing a sorted list of path names, each with permissions and the SHA-1 of a blob object. Its content can be listed through: user@user:/GIT/test# git ls-files --stage 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 README
Contains additional information about the repository.
Keeps records of changes made to refs.
In this directory the data of your Git objects is stored – all the contents of the files you have ever checked in, your commits, trees and tag objects. The files are stored by their SHA-1 values. The first two characters are for the subdirectory and the next 38 are the filename. For example, if the SHA-1 for a blob we’ve checked in is a576fac355dd17e39fd2671b010e36299f713b4d the path to the corresponding file is: [GIT_DIR]/objects/a5/76fac355dd17e39fd2671b010e36299f713b4d
This is the previous state of HEAD.
The file consists of packed heads and tags. It is useful for an efficient repository access.
This directory normally contains three subfolders – heads, remotes and tags. There you will find the corresponding local branches, remote branches and tags files.
For example, if you create a production branch, the file .git/refs/heads/production will be created and will contain the SHA-1 of the latest branch commit.