![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index 039a8598e3da230e0984127600470542c4897989..79884d9c74d3175e179dc5a83e9163908242d6ca 100644 (file)
$ man git-diff
------------------------------------------------
$ man git-diff
------------------------------------------------
+It is a good idea to introduce yourself to git 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
+------------------------------------------------
+
+
Importing a new project
-----------------------
Importing a new project
-----------------------
Git will reply
------------------------------------------------
Git will reply
------------------------------------------------
-defaulting to local storage area
+Initialized empty Git repository in .git/
------------------------------------------------
You've now initialized the working directory--you may notice a new
directory created, named ".git". Tell git that you want it to track
------------------------------------------------
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
+every file under the current directory with (notice the dot '.'
+that means the current directory):
------------------------------------------------
$ git add .
------------------------------------------------
$ git add .
Finally,
------------------------------------------------
Finally,
------------------------------------------------
-$ git commit -a
+$ git commit
------------------------------------------------
will prompt you for a commit message, then record the current state
------------------------------------------------
will prompt you for a commit message, then record the current state
$ git diff
------------------------------------------------
$ git diff
------------------------------------------------
-to review your changes. When you're done,
+to review your changes. When you're done, tell git that you
+want the updated contents of these files in the commit and then
+make a commit, like this:
------------------------------------------------
------------------------------------------------
-$ git commit -a
+$ git add file1 file...
+$ git commit
------------------------------------------------
------------------------------------------------
-will again prompt your for a message describing the change, and then
-record the new versions of the modified files.
+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.
+
+------------------------------------------------
+$ git commit -a
+------------------------------------------------
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
thorough description. Tools that turn commits into email, for
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
thorough description. Tools that turn commits into email, for
-example, use the first line on the Subject line and the rest of the
+example, use the first line on the Subject: line and the rest of the
commit in the body.
commit in the body.
-To add a new file, first create the file, then
-------------------------------------------------
-$ git add path/to/new/file
-------------------------------------------------
+Git tracks content not files
+----------------------------
+
+With git you have to explicitly "add" all the changed _content_ you
+want to commit together. This can be done in a few different ways:
+
+1) By using 'git add <file_spec>...'
+
+ This can be performed multiple times before a commit. Note that this
+ is not only for adding new files. Even modified files must be
+ added to the set of changes about to be committed. The "git status"
+ command gives you a summary of what is included so far for the
+ next commit. When done you should use the 'git commit' command to
+ make it real.
+
+ Note: don't forget to 'add' a file again if you modified it after the
+ first 'add' and before 'commit'. Otherwise only the previous added
+ state of that file will be committed. This is because git tracks
+ content, so what you're really 'add'ing to the commit is the *content*
+ of the file in the state it is in when you 'add' it.
+
+2) By using 'git commit -a' directly
+
+ This is a quick way to automatically 'add' the content from all files
+ that were modified since the previous commit, and perform the actual
+ commit without having to separately 'add' them beforehand. This will
+ not add content from new files i.e. files that were never added before.
+ Those files still have to be added explicitly before performing a
+ commit.
+
+But here's a twist. If you do 'git commit <file1> <file2> ...' then only
+the changes belonging to those explicitly specified files will be
+committed, entirely bypassing the current "added" changes. Those "added"
+changes will still remain available for a subsequent commit though.
+
+However, for normal usage you only have to remember 'git add' + 'git commit'
+and/or 'git commit -a'.
+
-then commit as usual. No special command is required when removing a
-file; just remove it, then commit.
+Viewing the changelog
+---------------------
At any point you can view the history of your changes using
At any point you can view the history of your changes using
$ git log -p
------------------------------------------------
$ git log -p
------------------------------------------------
+Often the overview of the change is useful to get a feel of
+each step
+
+------------------------------------------------
+$ git log --stat --summary
+------------------------------------------------
+
Managing branches
-----------------
Managing branches
-----------------
------------------------------------------------
at this point the two branches have diverged, with different changes
------------------------------------------------
at this point the two branches have diverged, with different changes
-made in each. To merge the changes made in the two branches, run
+made in each. To merge the changes made in experimental into master, run
------------------------------------------------
$ git pull . experimental
------------------------------------------------
$ git pull . experimental
will show a nice graphical representation of the resulting history.
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
If you develop on a branch crazy-idea, then regret it, you can always
delete the branch with
This creates a new directory "myrepo" containing a clone of Alice's
repository. The clone is on an equal footing with the original
This creates a new directory "myrepo" containing a clone of Alice's
repository. The clone is on an equal footing with the original
-project, posessing its own copy of the original project's history.
+project, possessing its own copy of the original project's history.
Bob then makes some changes and commits them:
Bob then makes some changes and commits them:
------------------------------------------------
$ cd /home/alice/project
------------------------------------------------
$ cd /home/alice/project
-$ git pull /home/bob/myrepo
+$ git pull /home/bob/myrepo master
------------------------------------------------
------------------------------------------------
-This actually pulls changes from the branch in Bob's repository named
-"master". Alice could request a different branch by adding the name
-of the branch to the end of the git pull command line.
+This merges the changes from Bob's "master" branch into Alice's
+current branch. If Alice has made her own changes in the meantime,
+then she may need to manually fix any conflicts. (Note that the
+"master" argument in the above command is actually unnecessary, as it
+is the default.)
-This merges Bob's changes into her repository; "git log" will
-now show the new commits. If Alice has made her own changes in the
-meantime, then Bob's changes will be merged in, and she will need to
-manually fix any conflicts.
+The "pull" command thus performs two operations: it fetches changes
+from a remote branch, then merges them into the current branch.
-A more cautious Alice might wish to examine Bob's changes before
-pulling them. She can do this by creating a temporary branch just
-for the purpose of studying Bob's changes:
+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:
-------------------------------------
$ git fetch /home/bob/myrepo master:bob-incoming
-------------------------------------
which fetches the changes from Bob's master branch into a new branch
-------------------------------------
$ git fetch /home/bob/myrepo master:bob-incoming
-------------------------------------
which fetches the changes from Bob's master branch into a new branch
-named bob-incoming. (Unlike git pull, git fetch just fetches a copy
-of Bob's line of development without doing any merging). Then
+named bob-incoming. Then
-------------------------------------
$ git log -p master..bob-incoming
-------------------------------------
$ git log -p master..bob-incoming
shows a list of all the changes that Bob made since he branched from
Alice's master branch.
shows a list of all the changes that Bob made since he branched from
Alice's master branch.
-After examing those changes, and possibly fixing things, Alice can
-pull the changes into her master branch:
+After examining those changes, and possibly fixing things, Alice
+could pull the changes into her master branch:
-------------------------------------
$ git checkout master
-------------------------------------
$ git checkout master
The last command is a pull from the "bob-incoming" branch in Alice's
own repository.
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:
+
+-------------------------------------
+$ git pull /home/bob/myrepo master:bob-incoming
+-------------------------------------
+
+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.
+
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
Note that he doesn't need to give the path to Alice's repository;
when Bob cloned Alice's repository, git stored the location of her
Note that he doesn't need to give the path to Alice's repository;
when Bob cloned Alice's repository, git stored the location of her
-repository in the file .git/remotes/origin, and that location is used
-as the default for pulls.
-
-Bob may also notice a branch in his repository that he didn't create:
+repository in the repository configuration, and that location is
+used for pulls:
-------------------------------------
-------------------------------------
-$ git branch
-* master
- origin
+$ git repo-config --get remote.origin.url
+/home/bob/myrepo
-------------------------------------
-------------------------------------
-The "origin" branch, which was created automatically by "git clone",
-is a pristine copy of Alice's master branch; Bob should never commit
-to it.
+(The complete configuration created by git-clone is visible using
+"git repo-config -l", and the gitlink:git-repo-config[1] man page
+explains the meaning of each option.)
+
+Git also keeps a pristine copy of Alice's master branch under the
+name "origin/master":
+
+-------------------------------------
+$ git branch -r
+ origin/master
+-------------------------------------
If Bob later decides to work from a different host, he can still
perform clones and pulls using the ssh protocol:
If Bob later decides to work from a different host, he can still
perform clones and pulls using the ssh protocol:
$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
-------------------------------------
$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
-------------------------------------
-But there other ways to refer to commits. You can use any initial
+But there are other ways to refer to commits. You can use any initial
part of the name that is long enough to uniquely identify the commit:
-------------------------------------
part of the name that is long enough to uniquely identify the commit:
-------------------------------------
$ git show experimental # the tip of the "experimental" branch
-------------------------------------
$ 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 show HEAD^ # to see the parent of HEAD
$ git branch stable v2.5 # start a new branch named "stable" based
# at v2.5
$ git reset --hard HEAD^ # reset your current branch and working
$ git branch stable v2.5 # start a new branch named "stable" based
# at v2.5
$ git reset --hard HEAD^ # reset your current branch and working
- # directory its state at HEAD^
+ # directory to its state at HEAD^
-------------------------------------
Be careful with that last command: in addition to losing any changes
-------------------------------------
Be careful with that last command: in addition to losing any changes
$ git grep "hello" v2.5
-------------------------------------
$ git grep "hello" v2.5
-------------------------------------
-searches for all occurences of "hello" in v2.5.
+searches for all occurrences of "hello" in v2.5.
If you leave out the commit name, git grep will search any of the
files it manages in your current directory. So
If you leave out the commit name, git grep will search any of the
files it manages in your current directory. So
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------
$ 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
-------------------------------------
Next Steps
smart enough to perform a close-to-optimal search even in the
case of complex non-linear history with lots of merged branches.
smart enough to perform a close-to-optimal search even in the
case of complex non-linear history with lots of merged branches.
- * link:everyday.html[Everday GIT with 20 Commands Or So]
+ * link:everyday.html[Everyday GIT with 20 Commands Or So]
* link:cvs-migration.html[git for CVS users].
* link:cvs-migration.html[git for CVS users].