way to do so is:
------------------------------------------------
-$ git repo-config --global user.name "Your Name Comes Here"
-$ git repo-config --global user.email you@yourdomain.example.com
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
------------------------------------------------
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.
+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.
+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 'adding' 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.
+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
------------------------------------------------
$ cd /home/alice/project
-$ git remote add bob /home/bob/myrepo
-$ git pull bob master
+$ git pull /home/bob/myrepo master
------------------------------------------------
-First it adds the "remote" Bob's repository with the name "bob" and
-then it merges the changes from Bob's "master" branch into Alice's
+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
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 without merging them with her own branch, 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 bob
-------------------------------------
-which fetches the changes from Bob's branches. 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/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
+After examining those changes, Alice
could merge the changes into her master branch:
-------------------------------------
-$ git checkout master
$ git merge bob/master
-------------------------------------
-The last command is a merge of the "bob/master" 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 bob
+$ git pull . remotes/bob/master
-------------------------------------
-This is just like the "git pull bob master" that we saw
-before, except that it also stores the unmerged changes from bob's
-master branch in bob/master 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
used for pulls:
-------------------------------------
-$ git repo-config --get remote.origin.url
+$ git config --get remote.origin.url
/home/bob/myrepo
-------------------------------------
(The complete configuration created by git-clone is visible using
-"git repo-config -l", and the gitlink:git-repo-config[1] man page
+"git config -l", and the gitlink:git-config[1] man page
explains the meaning of each option.)
Git also keeps a pristine copy of Alice's master branch under the
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
-publicly-visible branch that other developers pull from, as git will
-be confused by history that disappears in this way.)
+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.
+If you need to undo changes that you have pushed, use gitlink:git-revert[1]
+instead.
The git grep command can search for strings in any version of your
project, so