Git is best thought of as a tool for storing the history of a
collection of files. It does this by storing compressed snapshots of
-the contents of a file heirarchy, together with "commits" which show
+the contents of a file hierarchy, together with "commits" which show
the relationships between these snapshots.
Git provides extremely flexible and fast tools for exploring the
-------------------------------------------------
will use HEAD to produce a tar archive in which each filename is
-preceded by "prefix/".
+preceded by "project/".
If you're releasing a new version of a software project, you may want
to simultaneously make a changelog to include in the release
-------------------------------------------------
$ git diff --cached # difference between HEAD and the index; what
- # would be commited if you ran "commit" now.
+ # would be committed if you ran "commit" now.
$ git diff # difference between the index file and your
# working directory; changes that would not
# be included if you ran "commit" now.
++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
-------------------------------------------------
-Recall that the commit which will be commited after we resolve this
+Recall that the commit which will be committed after we resolve this
conflict will have two parents instead of the usual one: one parent
will be HEAD, the tip of the current branch; the other will be the
tip of the other branch, which is stored temporarily in MERGE_HEAD.
$ git reset --hard HEAD
-------------------------------------------------
-Or, if you've already commited the merge that you want to throw away,
+Or, if you've already committed the merge that you want to throw away,
-------------------------------------------------
$ git reset --hard ORIG_HEAD
-------------------------------------------------
Dangling objects are not a problem. At worst they may take up a little
-extra disk space. They can sometimes provide a last-resort method of
-recovery lost work--see <<dangling-objects>> for details. However, if
-you want, you may remove them with gitlink:git-prune[1] or the --prune
+extra disk space. They can sometimes provide a last-resort method for
+recovering lost work--see <<dangling-objects>> for details. However, if
+you wish, you can remove them with gitlink:git-prune[1] or the --prune
option to gitlink:git-gc[1]:
-------------------------------------------------
If you and the maintainer both have accounts on the same machine, then
you can just pull changes from each other's repositories directly;
-commands that accepts repository URLs as arguments will also accept a
+commands that accept repository URLs as arguments will also accept a
local directory name:
-------------------------------------------------
$ git pull /path/to/other/repository
-------------------------------------------------
+or an ssh url:
+
+-------------------------------------------------
+$ git clone ssh://yourhost/~you/repository
+-------------------------------------------------
+
+For projects with few developers, or for synchronizing a few private
+repositories, this may be all you need.
+
However, the more common way to do this is to maintain a separate public
repository (usually on a different host) for others to pull changes
from. This is usually more convenient, and allows you to cleanly
| they push V
their public repo <------------------- their repo
+We explain how to do this in the following sections.
+
[[setting-up-a-public-repository]]
Setting up a public repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ git push ssh://yourserver.com/~you/proj.git +master
-------------------------------------------------
+Note that the target of a "push" is normally a
+<<def_bare_repository,bare>> repository. You can also push to a
+repository that has a checked-out working tree, but the working tree
+will not be updated by the push. This may lead to unexpected results if
+the branch you push to is the currently checked-out branch!
+
As with git-fetch, you may also set up configuration options to
save typing; so, for example, after
haven't lost any information as long as you have the name of the tree
that it described.
-At the same time, the index is at the same time also the
-staging area for creating new trees, and creating a new tree always
-involves a controlled modification of the index file. In particular,
-the index file can have the representation of an intermediate tree that
-has not yet been instantiated. So the index can be thought of as a
-write-back cache, which can contain dirty information that has not yet
-been written back to the backing store.
+At the same time, the index is also the staging area for creating
+new trees, and creating a new tree always involves a controlled
+modification of the index file. In particular, the index file can
+have the representation of an intermediate tree that has not yet been
+instantiated. So the index can be thought of as a write-back cache,
+which can contain dirty information that has not yet been written back
+to the backing store.