![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index 036a27c41c7d64f44f032de79e29066c1222bbbf..384972cb9bb4a04c55bd8c4796bcd3408e44d5e9 100644 (file)
directory created, named ".git".
Next, tell git to take a snapshot of the contents of all files under the
directory created, named ".git".
Next, tell git to take a snapshot of the contents of all files under the
-current directory (note the '.'), with `git-add`:
+current directory (note the '.'), with 'git-add':
------------------------------------------------
$ git add .
------------------------------------------------
$ git add .
This snapshot is now stored in a temporary staging area which git calls
the "index". You can permanently store the contents of the index in the
This snapshot is now stored in a temporary staging area which git calls
the "index". You can permanently store the contents of the index in the
-repository with `git-commit`:
+repository with 'git-commit':
------------------------------------------------
$ git commit
------------------------------------------------
$ git commit
------------------------------------------------
You are now ready to commit. You can see what is about to be committed
------------------------------------------------
You are now ready to commit. You can see what is about to be committed
-using `git-diff` with the --cached option:
+using 'git-diff' with the --cached option:
------------------------------------------------
$ git diff --cached
------------------------------------------------
------------------------------------------------
$ git diff --cached
------------------------------------------------
-(Without --cached, `git-diff` will show you any changes that
+(Without --cached, 'git-diff' will show you any changes that
you've made but not yet added to the index.) You can also get a brief
you've made but not yet added to the index.) You can also get a brief
-summary of the situation with `git-status`:
+summary of the situation with 'git-status':
------------------------------------------------
$ git status
------------------------------------------------
$ git status
This will again prompt you for a message describing the change, and then
record a new version of the project.
This will again prompt you for a message describing the change, and then
record a new version of the project.
-Alternatively, instead of running `git-add` beforehand, you can use
+Alternatively, instead of running 'git-add' beforehand, you can use
------------------------------------------------
$ git commit -a
------------------------------------------------
$ git commit -a
Many revision control systems provide an `add` command that tells the
system to start tracking changes to a new file. Git's `add` command
Many revision control systems provide an `add` command that tells the
system to start tracking changes to a new file. Git's `add` command
-does something simpler and more powerful: `git-add` is used both for new
+does something simpler and more powerful: 'git-add' is used both for new
and newly modified files, and in both cases it takes a snapshot of the
given files and stages that content in the index, ready for inclusion in
the next commit.
and newly modified files, and in both cases it takes a snapshot of the
given files and stages that content in the index, ready for inclusion in
the next commit.
Bob begins with:
------------------------------------------------
Bob begins with:
------------------------------------------------
-$ git clone /home/alice/project myrepo
+bob$ git clone /home/alice/project myrepo
------------------------------------------------
This creates a new directory "myrepo" containing a clone of Alice's
------------------------------------------------
This creates a new directory "myrepo" containing a clone of Alice's
------------------------------------------------
(edit files)
------------------------------------------------
(edit files)
-$ git commit -a
+bob$ git commit -a
(repeat as necessary)
------------------------------------------------
(repeat as necessary)
------------------------------------------------
at /home/bob/myrepo. She does this with:
------------------------------------------------
at /home/bob/myrepo. She does this with:
------------------------------------------------
-$ cd /home/alice/project
-$ git pull /home/bob/myrepo master
+alice$ cd /home/alice/project
+alice$ git pull /home/bob/myrepo master
------------------------------------------------
This merges the changes from Bob's "master" branch into Alice's
------------------------------------------------
This merges the changes from Bob's "master" branch into Alice's
The "pull" command thus performs two operations: it fetches changes
from a remote branch, then merges them into the current branch.
The "pull" command thus performs two operations: it fetches changes
from a remote branch, then merges them into the current branch.
+Note that in general, Alice would want her local changes committed before
+initiating this "pull". If Bob's work conflicts with what Alice did since
+their histories forked, Alice will use her working tree and the index to
+resolve conflicts, and existing local changes will interfere with the
+conflict resolution process (git will still perform the fetch but will
+refuse to merge --- Alice will have to get rid of her local changes in
+some way and pull again when this happens).
+
+Alice can peek at what Bob did without merging first, using the "fetch"
+command; this allows Alice to inspect what Bob did, using a special
+symbol "FETCH_HEAD", in order to determine if he has anything worth
+pulling, like this:
+
+------------------------------------------------
+alice$ git fetch /home/bob/myrepo master
+alice$ git log -p HEAD..FETCH_HEAD
+------------------------------------------------
+
+This operation is safe even if Alice has uncommitted local changes.
+The range notation HEAD..FETCH_HEAD" means "show everything that is reachable
+from the FETCH_HEAD but exclude anything that is reachable from HEAD.
+Alice already knows everything that leads to her current state (HEAD),
+and reviewing what Bob has in his state (FETCH_HEAD) that she has not
+seen with this command
+
+If Alice wants to visualize what Bob did since their histories forked
+she can issue the following command:
+
+------------------------------------------------
+$ gitk HEAD..FETCH_HEAD
+------------------------------------------------
+
+This uses the same two-dot range notation we saw earlier with 'git log'.
+
+Alice may want to view what both of them did since they forked.
+She can use three-dot form instead of the two-dot form:
+
+------------------------------------------------
+$ gitk HEAD...FETCH_HEAD
+------------------------------------------------
+
+This means "show everything that is reachable from either one, but
+exclude anything that is reachable from both of them".
+
+Please note that these range notation can be used with both gitk
+and "git log".
+
+After inspecting what Bob did, if there is nothing urgent, Alice may
+decide to continue working without pulling from Bob. If Bob's history
+does have something Alice would immediately need, Alice may choose to
+stash her work-in-progress first, do a "pull", and then finally unstash
+her work-in-progress on top of the resulting history.
+
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:
------------------------------------------------
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
+alice$ git remote add bob /home/bob/myrepo
------------------------------------------------
------------------------------------------------
-With this, Alice can perform the first operation alone using the
-`git-fetch` command without merging them with her own branch,
+With this, Alice can perform the first part of the "pull" operation alone using the
+'git-fetch' command without merging them with her own branch,
using:
-------------------------------------
using:
-------------------------------------
-$ git fetch bob
+alice$ git fetch bob
-------------------------------------
Unlike the longhand form, when Alice fetches from Bob using a
-------------------------------------
Unlike the longhand form, when Alice fetches from Bob using a
-remote repository shorthand set up with `git-remote`, what was
+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:
-------------------------------------
fetched is stored in a remote tracking branch, in this case
`bob/master`. So after this:
-------------------------------------
-$ git log -p master..bob/master
+alice$ git log -p master..bob/master
-------------------------------------
shows a list of all the changes that Bob made since he branched from
-------------------------------------
shows a list of all the changes that Bob made since he branched from
could merge the changes into her master branch:
-------------------------------------
could merge the changes into her master branch:
-------------------------------------
-$ git merge bob/master
+alice$ git merge bob/master
-------------------------------------
This `merge` can also be done by 'pulling from her own remote
tracking branch', like this:
-------------------------------------
-------------------------------------
This `merge` can also be done by 'pulling from her own remote
tracking branch', like this:
-------------------------------------
-$ git pull . remotes/bob/master
+alice$ git pull . remotes/bob/master
-------------------------------------
Note that git pull always merges into the current branch,
-------------------------------------
Note that git pull always merges into the current branch,
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
-$ git pull
+bob$ git pull
-------------------------------------
Note that he doesn't need to give the path to Alice's repository;
-------------------------------------
Note that he doesn't need to give the path to Alice's repository;
used for pulls:
-------------------------------------
used for pulls:
-------------------------------------
-$ git config --get remote.origin.url
+bob$ git config --get remote.origin.url
/home/alice/project
-------------------------------------
/home/alice/project
-------------------------------------
-(The complete configuration created by `git-clone` is visible using
+(The complete configuration created by 'git-clone' is visible using
`git config -l`, and the linkgit:git-config[1] man page
explains the meaning of each option.)
`git config -l`, and the linkgit:git-config[1] man page
explains the meaning of each option.)
name "origin/master":
-------------------------------------
name "origin/master":
-------------------------------------
-$ git branch -r
+bob$ git branch -r
origin/master
-------------------------------------
origin/master
-------------------------------------
perform clones and pulls using the ssh protocol:
-------------------------------------
perform clones and pulls using the ssh protocol:
-------------------------------------
-$ git clone alice.org:/home/alice/project myrepo
+bob$ git clone alice.org:/home/alice/project myrepo
-------------------------------------
Alternatively, git has a native protocol, or can use rsync or http;
-------------------------------------
Alternatively, git has a native protocol, or can use rsync or http;
-----------------
Git history is represented as a series of interrelated commits. We
-----------------
Git history is represented as a series of interrelated commits. We
-have already seen that the `git-log` command can list those commits.
+have already seen that the 'git-log' command can list those commits.
Note that first line of each git log entry also gives a name for the
commit:
Note that first line of each git log entry also gives a name for the
commit:
merge-base: Clarify the comments on post processing.
-------------------------------------
merge-base: Clarify the comments on post processing.
-------------------------------------
-We can give this name to `git-show` to see the details about this
+We can give this name to 'git-show' to see the details about this
commit.
-------------------------------------
commit.
-------------------------------------
Be careful with that last command: in addition to losing any changes
in the working directory, it will also remove all later commits from
this branch. If this branch is the only branch containing those
Be careful with that last command: in addition to losing any changes
in the working directory, it will also remove all later commits from
this branch. If this branch is the only branch containing those
-commits, they will be lost. Also, don't use `git-reset` on a
+commits, they will be lost. Also, don't use 'git-reset' on a
publicly-visible branch that other developers pull from, as it will
force needless merges on other developers to clean up the history.
publicly-visible branch that other developers pull from, as it will
force needless merges on other developers to clean up the history.
-If you need to undo changes that you have pushed, use `git-revert`
+If you need to undo changes that you have pushed, use 'git-revert'
instead.
instead.
-The `git-grep` command can search for strings in any version of your
+The 'git-grep' command can search for strings in any version of your
project, so
-------------------------------------
project, so
-------------------------------------
searches for all occurrences 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
+If you leave out the commit name, 'git-grep' will search any of the
files it manages in your current directory. So
-------------------------------------
files it manages in your current directory. So
-------------------------------------
is a quick way to search just the files that are tracked by git.
Many git commands also take sets of commits, which can be specified
is a quick way to search just the files that are tracked by git.
Many git commands also take sets of commits, which can be specified
-in a number of ways. Here are some examples with `git-log`:
+in a number of ways. Here are some examples with 'git-log':
-------------------------------------
$ git log v2.5..v2.6 # commits between v2.5 and v2.6
-------------------------------------
$ git log v2.5..v2.6 # commits between v2.5 and v2.6
# Makefile
-------------------------------------
# Makefile
-------------------------------------
-You can also give `git-log` a "range" of commits where the first is not
+You can also give 'git-log' a "range" of commits where the first is not
necessarily an ancestor of the second; for example, if the tips of
the branches "stable-release" and "master" diverged from a common
commit some time ago, then
necessarily an ancestor of the second; for example, if the tips of
the branches "stable-release" and "master" diverged from a common
commit some time ago, then
will show the list of commits made on the stable branch but not
the experimental branch.
will show the list of commits made on the stable branch but not
the experimental branch.
-The `git-log` command has a weakness: it must present commits in a
+The 'git-log' command has a weakness: it must present commits in a
list. When the history has lines of development that diverged and
list. When the history has lines of development that diverged and
-then merged back together, the order in which `git-log` presents
+then merged back together, the order in which 'git-log' presents
those commits is meaningless.
Most projects with multiple contributors (such as the linux kernel,
those commits is meaningless.
Most projects with multiple contributors (such as the linux kernel,
-or git itself) have frequent merges, and `gitk` does a better job of
+or git itself) have frequent merges, and 'gitk' does a better job of
visualizing their history. For example,
-------------------------------------
visualizing their history. For example,
-------------------------------------
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------
-You can also use `git-show` to see any such file:
+You can also use 'git-show' to see any such file:
-------------------------------------
$ git show v2.5:Makefile
-------------------------------------
$ git show v2.5:Makefile