Documentation / gitrepository-layout.txton commit Update draft release notes to 2.1 (50f84e3)
   1gitrepository-layout(5)
   2=======================
   3
   4NAME
   5----
   6gitrepository-layout - Git Repository Layout
   7
   8SYNOPSIS
   9--------
  10$GIT_DIR/*
  11
  12DESCRIPTION
  13-----------
  14
  15A Git repository comes in two different flavours:
  16
  17 * a `.git` directory at the root of the working tree;
  18
  19 * a `<project>.git` directory that is a 'bare' repository
  20   (i.e. without its own working tree), that is typically used for
  21   exchanging histories with others by pushing into it and fetching
  22   from it.
  23
  24*Note*: Also you can have a plain text file `.git` at the root of
  25your working tree, containing `gitdir: <path>` to point at the real
  26directory that has the repository.  This mechanism is often used for
  27a working tree of a submodule checkout, to allow you in the
  28containing superproject to `git checkout` a branch that does not
  29have the submodule.  The `checkout` has to remove the entire
  30submodule working tree, without losing the submodule repository.
  31
  32These things may exist in a Git repository.
  33
  34objects::
  35        Object store associated with this repository.  Usually
  36        an object store is self sufficient (i.e. all the objects
  37        that are referred to by an object found in it are also
  38        found in it), but there are a few ways to violate it.
  39+
  40. You could have an incomplete but locally usable repository
  41by creating a shallow clone.  See linkgit:git-clone[1].
  42. You could be using the `objects/info/alternates` or
  43`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanisms to 'borrow'
  44objects from other object stores.  A repository with this kind
  45of incomplete object store is not suitable to be published for
  46use with dumb transports but otherwise is OK as long as
  47`objects/info/alternates` points at the object stores it
  48borrows from.
  49
  50objects/[0-9a-f][0-9a-f]::
  51        A newly created object is stored in its own file.
  52        The objects are splayed over 256 subdirectories using
  53        the first two characters of the sha1 object name to
  54        keep the number of directory entries in `objects`
  55        itself to a manageable number. Objects found
  56        here are often called 'unpacked' (or 'loose') objects.
  57
  58objects/pack::
  59        Packs (files that store many object in compressed form,
  60        along with index files to allow them to be randomly
  61        accessed) are found in this directory.
  62
  63objects/info::
  64        Additional information about the object store is
  65        recorded in this directory.
  66
  67objects/info/packs::
  68        This file is to help dumb transports discover what packs
  69        are available in this object store.  Whenever a pack is
  70        added or removed, `git update-server-info` should be run
  71        to keep this file up-to-date if the repository is
  72        published for dumb transports.  'git repack' does this
  73        by default.
  74
  75objects/info/alternates::
  76        This file records paths to alternate object stores that
  77        this object store borrows objects from, one pathname per
  78        line. Note that not only native Git tools use it locally,
  79        but the HTTP fetcher also tries to use it remotely; this
  80        will usually work if you have relative paths (relative
  81        to the object database, not to the repository!) in your
  82        alternates file, but it will not work if you use absolute
  83        paths unless the absolute path in filesystem and web URL
  84        is the same. See also 'objects/info/http-alternates'.
  85
  86objects/info/http-alternates::
  87        This file records URLs to alternate object stores that
  88        this object store borrows objects from, to be used when
  89        the repository is fetched over HTTP.
  90
  91refs::
  92        References are stored in subdirectories of this
  93        directory.  The 'git prune' command knows to preserve
  94        objects reachable from refs found in this directory and
  95        its subdirectories.
  96
  97refs/heads/`name`::
  98        records tip-of-the-tree commit objects of branch `name`
  99
 100refs/tags/`name`::
 101        records any object name (not necessarily a commit
 102        object, or a tag object that points at a commit object).
 103
 104refs/remotes/`name`::
 105        records tip-of-the-tree commit objects of branches copied
 106        from a remote repository.
 107
 108refs/replace/`<obj-sha1>`::
 109        records the SHA-1 of the object that replaces `<obj-sha1>`.
 110        This is similar to info/grafts and is internally used and
 111        maintained by linkgit:git-replace[1]. Such refs can be exchanged
 112        between repositories while grafts are not.
 113
 114packed-refs::
 115        records the same information as refs/heads/, refs/tags/,
 116        and friends record in a more efficient way.  See
 117        linkgit:git-pack-refs[1].
 118
 119HEAD::
 120        A symref (see glossary) to the `refs/heads/` namespace
 121        describing the currently active branch.  It does not mean
 122        much if the repository is not associated with any working tree
 123        (i.e. a 'bare' repository), but a valid Git repository
 124        *must* have the HEAD file; some porcelains may use it to
 125        guess the designated "default" branch of the repository
 126        (usually 'master').  It is legal if the named branch
 127        'name' does not (yet) exist.  In some legacy setups, it is
 128        a symbolic link instead of a symref that points at the current
 129        branch.
 130+
 131HEAD can also record a specific commit directly, instead of
 132being a symref to point at the current branch.  Such a state
 133is often called 'detached HEAD.'  See linkgit:git-checkout[1]
 134for details.
 135
 136branches::
 137        A slightly deprecated way to store shorthands to be used
 138        to specify a URL to 'git fetch', 'git pull' and 'git push'.
 139        A file can be stored as `branches/<name>` and then
 140        'name' can be given to these commands in place of
 141        'repository' argument.  See the REMOTES section in
 142        linkgit:git-fetch[1] for details.  This mechanism is legacy
 143        and not likely to be found in modern repositories.
 144
 145hooks::
 146        Hooks are customization scripts used by various Git
 147        commands.  A handful of sample hooks are installed when
 148        'git init' is run, but all of them are disabled by
 149        default.  To enable, the `.sample` suffix has to be
 150        removed from the filename by renaming.
 151        Read linkgit:githooks[5] for more details about
 152        each hook.
 153
 154index::
 155        The current index file for the repository.  It is
 156        usually not found in a bare repository.
 157
 158info::
 159        Additional information about the repository is recorded
 160        in this directory.
 161
 162info/refs::
 163        This file helps dumb transports discover what refs are
 164        available in this repository.  If the repository is
 165        published for dumb transports, this file should be
 166        regenerated by 'git update-server-info' every time a tag
 167        or branch is created or modified.  This is normally done
 168        from the `hooks/update` hook, which is run by the
 169        'git-receive-pack' command when you 'git push' into the
 170        repository.
 171
 172info/grafts::
 173        This file records fake commit ancestry information, to
 174        pretend the set of parents a commit has is different
 175        from how the commit was actually created.  One record
 176        per line describes a commit and its fake parents by
 177        listing their 40-byte hexadecimal object names separated
 178        by a space and terminated by a newline.
 179+
 180Note that the grafts mechanism is outdated and can lead to problems
 181transferring objects between repositories; see linkgit:git-replace[1]
 182for a more flexible and robust system to do the same thing.
 183
 184info/exclude::
 185        This file, by convention among Porcelains, stores the
 186        exclude pattern list. `.gitignore` is the per-directory
 187        ignore file.  'git status', 'git add', 'git rm' and
 188        'git clean' look at it but the core Git commands do not look
 189        at it.  See also: linkgit:gitignore[5].
 190
 191info/sparse-checkout::
 192        This file stores sparse checkout patterns.
 193        See also: linkgit:git-read-tree[1].
 194
 195remotes::
 196        Stores shorthands for URL and default refnames for use
 197        when interacting with remote repositories via 'git fetch',
 198        'git pull' and 'git push' commands.  See the REMOTES section
 199        in linkgit:git-fetch[1] for details.  This mechanism is legacy
 200        and not likely to be found in modern repositories.
 201
 202logs::
 203        Records of changes made to refs are stored in this
 204        directory.  See linkgit:git-update-ref[1]
 205        for more information.
 206
 207logs/refs/heads/`name`::
 208        Records all changes made to the branch tip named `name`.
 209
 210logs/refs/tags/`name`::
 211        Records all changes made to the tag named `name`.
 212
 213shallow::
 214        This is similar to `info/grafts` but is internally used
 215        and maintained by shallow clone mechanism.  See `--depth`
 216        option to linkgit:git-clone[1] and linkgit:git-fetch[1].
 217
 218modules::
 219        Contains the git-repositories of the submodules.
 220
 221SEE ALSO
 222--------
 223linkgit:git-init[1],
 224linkgit:git-clone[1],
 225linkgit:git-fetch[1],
 226linkgit:git-pack-refs[1],
 227linkgit:git-gc[1],
 228linkgit:git-checkout[1],
 229linkgit:gitglossary[7],
 230link:user-manual.html[The Git User's Manual]
 231
 232GIT
 233---
 234Part of the linkgit:git[1] suite.