整理自Git文件夹下资料及man手册（不包括书籍）
$ git commit -a
which will automatically notice any modified (but not new) files, add them to the index, and commit, all in one step.
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 commit in the body.
If you also want to see complete diffs at each step, use
$ git log -p
Often the overview of the change is useful to get a feel of each step
$ git log --stat --summary
bai@bbox:~/t-git/push1$ git log --stat --summary --oneline
f441901 modified pushfile1 and touch a new file1
pushfile1 | 2 ++
1 file changed, 2 insertions(+)
ece9c28 changed pushfile1
pushfile1 | 1 +
1 file changed, 1 insertion(+)
8832efc changed pushfile1
pushfile1 | 1 +
1 file changed, 1 insertion(+)
d8ff449 add pushfile1 in push1
0 files changed
create mode 100644 pushfile1
73a5adf inital commit
0 files changed
create mode 100644 README
bai@bbox:~/t-git/push1$
In git 1.7.0 or later, to cancel a conflicting merge, use git reset --merge. Warning: In older versions of git, running git pull with
uncommitted changes is discouraged: while possible, it leaves you in a state that may be hard to back out of in the case of a conflict.
If any of the remote changes overlap with local uncommitted changes, the merge will be automatically cancelled and the work tree untouched.
It is generally best to get any local changes in working order before pulling or stash them away with git-stash(1).
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 reviews what Bob has in his state (FETCH_HEAD) that she has not seen with this command.
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".
Note that first line of each git log entry also gives a name for the commit:
$ git log
commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
Author: Junio C Hamano <junkio@cox.net>
Date: Tue May 16 17:18:22 2006 -0700
merge-base: Clarify the comments on post processing.
We can give this name to git show to see the details about this commit.
$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
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:
$ git show c82a22c39c # the first few characters of the name are
# usually enough
$ git show HEAD # the tip of the current branch
$ git show experimental # the tip of the "experimental" branch
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
Note that merge commits may have more than one parent:
$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
$ git show HEAD^2 # show the second parent of HEAD
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^
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.
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
<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb
Output from git describe; i.e. a closest tag, optionally followed by a dash and a number of commits, followed by a dash, a g, and an
abbreviated object name.
The number of additional commits is the number of commits which would be displayed by "git log v1.0.4..parent". The hash suffix is "-g" +
7-char abbreviation for the tip commit of parent (which was 2414721b194453f058079d897d13c4e377f92dc6). The "g" prefix stands for "git" and
is used to allow describing the version of a software depending on the SCM the software is managed with. This is useful in an environment
where people may use different SCMs.
<rev>:<path>, e.g. HEAD:README, :README, master:./README
A suffix : followed by a path names the blob or tree at the given path in the tree-ish object named by the part before the colon. :path
(with an empty part before the colon) is a special case of the syntax described next: content recorded in the index at the given path. A
path starting with ./ or ../ is relative to the current working directory. The given path will be converted to be relative to the
working tree’s root directory. This is most useful to address a blob or tree from a commit or tree that has the same tree structure as
the working tree.
<refname>, e.g. master, heads/master, refs/heads/master
A symbolic ref name. E.g. master typically means the commit object referenced by refs/heads/master. If you happen to have both
heads/master and tags/master, you can explicitly say heads/master to tell git which one you mean.
HEAD names the commit on which you based the changes in the working tree. FETCH_HEAD records the branch which you fetched from a
remote repository with your last git fetch invocation. ORIG_HEAD is created by commands that move your HEAD in a drastic way, to
record the position of the HEAD before their operation, so that you can easily change the tip of the branch back to the state before
you ran them. MERGE_HEAD records the commit(s) which you are merging into your branch when you run git merge. CHERRY_PICK_HEAD
records the commit which you are cherry-picking when you run git cherry-pick.
Note that any of the refs/* cases above may come either from the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file.
G H I J
\ / \ /
D E F
\ | / \
\ | / |
\|/ |
B C
\ /
\ /
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2 = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
To exclude commits reachable from a commit, a prefix ^ notation is used. E.g. ^r1 r2 means commits reachable from r2 but exclude the ones
reachable from r1.
The r1^@ notation means all parents of r1.r1^! includes commit r1 but excludes all of its parents.
Here are a handful of examples:
D G H D
D F G H I J D F
^G D H D
^D B E I J F B
B...C G H D E B C
^D B C E I J F B C
C^@ I J F
F^! D G H D F
The first and second above is sometimes wrong,e.g.
git cherry-pick master
Apply the change introduced by the commit at the tip of the master branch and create a new commit with this change.
git cherry-pick master~4 master~2
Apply the changes introduced by the fifth and third last commits pointed to by master and create 2 new commits with these changes.
git cherry-pick -n master~1 next
Apply to the working tree and the index the changes introduced by the second last commit pointed to by master and by the last commit
pointed to by next, but do not create any commit with these changes.
git diff [--options] <commit> <commit> [--] [<path>...]
This is to view the changes between two arbitrary <commit>.
git diff [--options] <commit>..<commit> [--] [<path>...]
This is synonymous to the previous form. If <commit> on one side is omitted, it will have the same effect as using HEAD instead.
git diff [--options] <commit>...<commit> [--] [<path>...]
This form is to view the changes on the branch containing and up to the second <commit>, starting at a common ancestor of both
<commit>. "git diff A...B" is equivalent to "git diff $(git-merge-base A B) B". You can omit any one of <commit>, which has the same
effect as using HEAD instead.
For a more complete list of ways to spell <commit>, see "SPECIFYING REVISIONS" section in gitrevisions(7). However, "diff" is about
comparing two endpoints, not ranges, and the range notations ("<commit>..<commit>" and "<commit>...<commit>") do not mean a range as
defined in the "SPECIFYING RANGES" section in gitrevisions(7).
Create a bare repository to publish your changes to the public:
$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
So,bare repository 应该是用来作为中心服务器上的公共repo来使用的，在工作机上最好用带有workig tree的repo.
refs:heads,remotes,tags
object:commit,tree,blob
<<<<<<<<<<《GIt Community》
分支(branch), 远程跟踪分支(remote-tracking branch)以及标签(tag)都是对提交的引用. 所有的引用是用"refs"开头, 以斜杠分割的路径. 到目前为此, 我们用到的引用名称其实是它们的简写版本:
- 分支"test"是"refs/heads/test"的简写.
- 标签"v2.6.18"是"refs/tags/v2.6.18"的简写.
- "origin/master"是"refs/remotes/origin/master"的简写.
每个对象(object) 包括三个部分:类型 大小和内容。大小就是指内容的大小,内容取决于对象的类型,有四种类型的对象:"blob"、"tree"、 "commit" 和"tag"。
• “blob”用来存储文件数据,通常是一个文件。
• “tree”有点像一个目录,它管理一些“tree”或是 “blob”(就像文件和子目录)
• 一个“commit”只指向一个"tree",它用来标记项目某一个特定时间点的状态。它包括一些关于时间点的元数据,如时间戳、最近一次提交的作者、指向上次提交(commits)的指针等等。
• 一个“tag”是来标记某一个提交(commit) 的方法。
commit
• 作者 : 做了此次修改的人的名字, 还有修改日期.
• 提交者
提交者(committer): 实际创建提交(commit)的人的名字, 同时也带有提交日期. TA可能会和作者不是同一
个人; 例如作者写一个补丁(patch)并把它用邮件发给提交者, 由他来创建提交(commit).
一个标签对象包括一个对象名(译者注:就是SHA1签名), 对象类型, 标签名, 标签创建人的名字("tagger"), 还有一条可能包含有签名(signature)的消息
点击 git tag, 可以了解如何创建和验证标签对象. (注意: git tag 同样也可以用来创建 "轻量级的标签"(lightweight tags),但它们并不是标签对象, 而只一些以 "refs/tags/" 开头的引用罢了).
If one of -a, -s, or -u <key-id> is passed, git tag creates a tag object, and requires a tag message.Otherwise just a tag reference for the SHA1 object name of the commit object is created (i.e. a lightweight tag).
In general, it's very important to write a good commit message. For open source projects, it's generally a rule to write your message more or less in this format:
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); some git tools can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary
here
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: hello.rb
#
~
~
~
".git/COMMIT_EDITMSG" 25L, 884C written
· References to commit objects at the head of each branch are stored in files under .git/refs/heads/.
· The name of the current branch is stored in .git/HEAD.
So,"merging upwards" means being merged to the upstream,e.g. linus merges other maintainers' branches(cherry-pick),while other developers get linux mainline using git merge,which calls "merging downwards".<<<<man Gitworkflows
