should never have any real reason to
look at the objects directly, but you might want to know that these
objects are what contains all the real 'data' in your repository.
- a subdirectory called `refs`, which contains references to objects.
In particular, the `refs` subdirectory will contain two other
subdirectories, named `heads` and `tags` respectively. They do
exactly what their names imply: they contain references to any number
of different 'heads' of development (aka 'branches'), and to any
'tags' that you have created to name specific versions in your
repository.
One note: the special `master` head is the default branch, which is
why the `.git/HEAD` file was created points to it even if it
doesn't yet exist. Basically, the `HEAD` link is supposed to always
point to the branch you are working on right now, and you always
start out expecting to work on the `master` branch.
However, this is only a convention, and you can name your branches
anything you want, and don't have to ever even 'have' a `master`
branch. A number of the Git tools will assume that `.git/HEAD` is
valid, though.
[NOTE]
An 'object' is identified by its 160-bit SHA-1 hash, aka 'object name',
and a reference to an object is always the 40-byte hex
representation of that SHA-1 name. The files in the `refs`
subdirectory are expected to contain these hex references
(usually with a final `\n` at the end), and you should thus
expect to see a number of 41-byte files containing these
references in these `refs` subdirectories when you actually start
populating your tree.
[NOTE]
An advanced user may want to take a look at linkgit:gitrepository-layout[5]
after finishing this tutorial.
You have now created your first Git repository. Of course, since it's
empty, that's not very useful, so let's start populating it with data.
Populating a Git repository
---------------------------
We'll keep this simple and stupid, so we'll start off with populating a
few trivial files just to get a feel for it.
Start off with just creating any random files that you want to maintain
in your Git repository. We'll start off with a few bad examples, just to
get a feel for how this works:
------------------------------------------------
$ echo "Hello World" >hello
$ echo "Silly example" >example
------------------------------------------------
you have now created two files in your working tree (aka 'working directory'),
but to actually check in your hard work, you will have to go through two steps:
- fill in the 'index' file (aka 'cache') with the information about your
working tree state.
- commit that index file as an object.
The first step is trivial: when you want to tell Git about any changes
to your working tree, you use the 'git update-index' program. That
program normally just takes a list of filenames you want to update, but
to avoid trivial mistakes, it refuses to add new entries to the index
(or remove existing ones) unless you explicitly tell it that you're
adding a new entry with the `--add` flag (or removing an entry with the
`--remove`) flag.
So to populate the index with the two files you just created, you can do
------------------------------------------------
$ git update-index --add hello example
------------------------------------------------
and you have now told Git to track those two files.
In fact, as you did that, if you now look into your object directory,
you'll notice that Git will have added two new objects to the object
database. If you did exactly the steps above, you should now be able to do
----------------
$ ls .git/objects/??/*
----------------
and see two files:
----------------
.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962
----------------
which correspond with the objects with names of `557db...` and
`f24c7...` respectively.
If you want to, you can use 'git cat-file' to look at those objects, but
you'll have to use the object name, not the filename of