![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index aa8ea307966916c70a75595d06f5ba4c32c2530b..c27a4505d48c838b33e07bd3a2878211dfeee15d 100644 (file)
$ man git-diff
------------------------------------------------
-It is a good idea to introduce yourself to git before doing any
-operation. The easiest way to do so is:
+It is a good idea to introduce yourself to git with your name and
+public email address before doing any operation. The easiest
+way to do so is:
------------------------------------------------
-$ cat >~/.gitconfig <<\EOF
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
-EOF
+$ git repo-config --global user.name "Your Name Comes Here"
+$ git repo-config --global user.email you@yourdomain.example.com
------------------------------------------------
------------------------------------------------
$ tar xzf project.tar.gz
$ cd project
-$ git init-db
+$ git init
------------------------------------------------
Git will reply
You've now initialized the working directory--you may notice a new
directory created, named ".git". Tell git that you want it to track
-every file under the current directory with (notice the dot '.'
-that means the current directory):
+every file under the current directory (note the '.') with:
------------------------------------------------
$ git add .
will prompt you for a commit message, then record the current state
of all the files to the repository.
+Making changes
+--------------
+
Try modifying some files, then run
------------------------------------------------
make a commit, like this:
------------------------------------------------
-$ git add file1 file...
+$ git add file1 file2 file3
$ git commit
------------------------------------------------
This will again prompt your for a message describing the change, and then
-record the new versions of the files you listed. It is cumbersome
-to list all files and you can say `git commit -a` (which stands for 'all')
-instead of running `git add` beforehand.
+record the new versions of the files you listed.
+
+Alternatively, instead of running `git add` beforehand, you can use
------------------------------------------------
$ git commit -a
------------------------------------------------
+which will automatically notice modified (but not new) files.
+
A note on commit messages: Though not required, it's a good idea to
begin the commit message with a single short (less than 50 character)
line summarizing the change, followed by a blank line and then a more
made in each. To merge the changes made in experimental into master, run
------------------------------------------------
-$ git pull . experimental
+$ git merge experimental
------------------------------------------------
If the changes don't conflict, you're done. If there are conflicts,
will show a nice graphical representation of the resulting history.
+At this point you could delete the experimental branch with
+
+------------------------------------------------
+$ git branch -d experimental
+------------------------------------------------
+
+This command ensures that the changes in the experimental branch are
+already in the current branch.
+
If you develop on a branch crazy-idea, then regret it, you can always
delete the branch with
The "pull" command thus performs two operations: it fetches changes
from a remote branch, then merges them into the current branch.
-You can perform the first operation alone using the "git fetch"
-command. For example, Alice could create a temporary branch just to
-track Bob's changes, without merging them with her own, using:
+When you are working in a small closely knit group, it is not
+unusual to interact with the same repository over and over
+again. By defining 'remote' repository shorthand, you can make
+it easier:
+
+------------------------------------------------
+$ git remote add bob /home/bob/myrepo
+------------------------------------------------
+
+With this, you can perform the first operation alone using the
+"git fetch" command without merging them with her own branch,
+using:
-------------------------------------
-$ git fetch /home/bob/myrepo master:bob-incoming
+$ git fetch bob
-------------------------------------
-which fetches the changes from Bob's master branch into a new branch
-named bob-incoming. Then
+Unlike the longhand form, when Alice fetches from Bob using a
+remote repository shorthand set up with `git remote`, what was
+fetched is stored in a remote tracking branch, in this case
+`bob/master`. So after this:
-------------------------------------
-$ git log -p master..bob-incoming
+$ git log -p master..bob/master
-------------------------------------
shows a list of all the changes that Bob made since he branched from
Alice's master branch.
-After examining those changes, and possibly fixing things, Alice
-could pull the changes into her master branch:
+After examining those changes, Alice
+could merge the changes into her master branch:
-------------------------------------
-$ git checkout master
-$ git pull . bob-incoming
+$ git merge bob/master
-------------------------------------
-The last command is a pull from the "bob-incoming" branch in Alice's
-own repository.
-
-Alice could also perform both steps at once with:
+This `merge` can also be done by 'pulling from her own remote
+tracking branch', like this:
-------------------------------------
-$ git pull /home/bob/myrepo master:bob-incoming
+$ git pull . remotes/bob/master
-------------------------------------
-This is just like the "git pull /home/bob/myrepo master" that we saw
-before, except that it also stores the unmerged changes from bob's
-master branch in bob-incoming before merging them into Alice's
-current branch. Note that git pull always merges into the current
-branch, regardless of what else is given on the commandline.
+Note that git pull always merges into the current branch,
+regardless of what else is given on the commandline.
Later, Bob can update his repo with Alice's latest changes using
$ git show experimental # the tip of the "experimental" branch
-------------------------------------
-Every commit has at least one "parent" commit, which points to the
-previous state of the project:
+Every commit usually has one "parent" commit
+which points to the previous state of the project:
-------------------------------------
$ git show HEAD^ # to see the parent of HEAD
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------
-You can also use "git cat-file -p" to see any such file:
+You can also use "git show" to see any such file:
-------------------------------------
-$ git cat-file -p v2.5:Makefile
+$ git show v2.5:Makefile
-------------------------------------
Next Steps