Git Tutorial
https://www.atlassian.com/git/tutorials/
https://git-scm.com/docs/gittutorial - done reading
http://rogerdudler.github.io/git-guide/
https://www.git-tower.com/blog/git-for-subversion-users-cheat-sheet/
git help config
git config --global user.name "Your Name"
git config --global user.email "Your Email"
cd project
git init
git add .
git commit -m "Commit message"
git add file1 file2 file3
git diff --cached
Without the --cached option, 'git diff' will show you any changes that you've
made but not yet added to the staging area.
git status
git reset HEAD fileName // Unstage a file
git commit -a
The above command automatically add any modified (but not new) files to the
staging area, and commit, all in one step.
Though not required, it is a good idea to begin the commit message with a single
short (less than 50 characters) line summarizing the change, followed by a blank
line, and then a more thorough description. The text up to the first blank line
in a commit message is treated as the commit title, and that title is used
throughout Git. For example, git-format-patch turns a commit into email, and it
uses the title as the Subject line, and the rest of the commit in the body.
git log
git log -p // see the complete diffs at each step
git log --stat --summary // see just an overview of the change
git branch branchName // create a local branch
git branch // list existing local branches
git branch -a // list existing branches, including remote branches
The "master" branch is a default branch that was created for you automatically.
The asterisk indicate the current branch.
git checkout experimental // switch to a local branch named "experimental"
git checkout master // switch back to the local branch named "master"
git merge experimental // merged changes from the local branch named "experimental"
// into the current branch.
git branch -d experimental // delete a local branch named "experimental"
Suppose that Alice has started a new project with a Git repository in
/home/alice/project, and that Bob, who has a home directory on the same machine
want to contribute. Bob begins with:
git clone /home/alice/project myrepo
This creates a new directory named myrepo containing a clone of Alice's
repository. The clone is on an equal footing with the original project,
possessing its own copy of the original project's history. Bob then make some
changes and commits them. When he is ready, he tells Alice to pull changes
from his repository at /home/bob/myrepo. Alice does with this:
cd /home/alice/project
git pull /home/bob/myrepo master
This merge the changes from Bob's master branch into Alice's current branch. If
Alice has made her own changes in the meantime, she may need to manually fix any
conflicts.
In general, we would want to commit our local changes before doing a 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:
git fetch /home/bob/myrepo master
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 reviews 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
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".
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:
git remote add bob /home/bob/myrepo
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:
git fetch bob
git log -p master..bob/master
The above command shows a list of all the changes that Bob made since he
branched from Alice’s master branch.
After examining those changes, Alice could merge the changes into her master
branch:
git merge bob/master
This merge can also be done by pulling from her own remote-tracking branch,
like this:
git pull . remotes/bob/master
Note that git pull always merges into the current branch, regardless of what
else is given on the command line.
Later, Bob can update his repo with Alice’s latest changes using:
git pull
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
repository configuration, and that location is used for pulls:
git config --get remote.origin.url
Git also keeps a pristine copy of Alice’s master branch under the name
"origin/master":
git branch -r
git show c82a22c39c
git show HEAD // Tip of the current branch
git show experimental // Tip of the local branch named "experimental"
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 grandparent of HEAD
git show HEAD~4 # to see the great-great grandparent of HEAD
git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
git show HEAD^2 # show the second parent of HEAD
Every commit usually has one "parent" commit which points to the previous state
of the project. Merge commits may have more than one parent. What does this
mean?
You can also give commits names of your own after running:
git tag v2.5 1b2e1d63ff
We can refer to 1b2e1d63ff by the name "v2.5". If you intend to share this name
with other people (for example, to identify a release version), you should
create a "tag" object, and perhaps sign it; see git-tag[1] for details.
Any Git command that needs to know a commit can take any of these names. For
example:
git diff v2.5 HEAD # compare the current HEAD to v2.5
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 to its state at HEAD^
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 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
instead.
The git grep command can search for strings in any version of your project. For
example:
git grep "hello" 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.
Many Git commands also take sets of commits, which can be specified 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.. # commits since v2.5
git log --since="2 weeks ago" # commits from the last 2 weeks
git log v2.5.. Makefile # commits since v2.5 which modify
# Makefile
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" and "master" diverged from a common commit some time ago, then
git log stable..master
will list commits made in the master branch but not in the stable branch, while
git log master..stable
will show the list of commits made on the stable branch but not the master
branch.
The git log command has a weakness: it must present commits in a list. When the
history has lines of development that diverged and 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, or Git
itself) have frequent merges, and gitk does a better job of visualizing their
history. For example,
gitk --since="2 weeks ago" drivers/
allows you to browse any commits from the last 2 weeks of commits that modified
files under the "drivers" directory. (Note: you can adjust gitk’s fonts by
holding down the control key while pressing "-" or "+".)
Finally, most commands that take filenames will optionally allow you to precede
any filename by a commit, to specify a particular version of the file:
git diff v2.5:Makefile HEAD:Makefile.in
You can also use git show to see any such file:
git show v2.5:Makefile
page revision: 7, last edited: 07 Jan 2017 22:24