Git User Manual
===============
Git is a fast distributed revision control system.
This manual is designed to be readable by someone with basic UNIX
command-line skills, but no previous knowledge of Git.
<<repositories-and-branches>> and <<exploring-git-history>> explain how
to fetch and study a project using git--read these chapters to learn how
to build and test a particular version of a software project, search for
regressions, and so on.
People needing to do actual development will also want to read
<<Developing-With-git>> and <<sharing-development>>.
Further chapters cover more specialized topics.
Comprehensive reference documentation is available through the man
pages, or linkgit:git-help[1] command. For example, for the command
`git clone <repo>`, you can either use:
------------------------------------------------
$ man git-clone
------------------------------------------------
or:
------------------------------------------------
$ git help clone
------------------------------------------------
With the latter, you can use the manual viewer of your choice; see
linkgit:git-help[1] for more information.
See also <<git-quick-start>> for a brief overview of Git commands,
without any explanation.
Finally, see <<todo>> for ways that you can help make this manual more
complete.
[[repositories-and-branches]]
Repositories and Branches
=========================
[[how-to-get-a-git-repository]]
How to get a Git repository
---------------------------
It will be useful to have a Git repository to experiment with as you
read this manual.
The best way to get one is by using the linkgit:git-clone[1] command to
download a copy of an existing repository. If you don't already have a
project in mind, here are some interesting examples:
------------------------------------------------
# Git itself (approx. 40MB download):
$ git clone git://git.kernel.org/pub/scm/git/git.git
# the Linux kernel (approx. 640MB download):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
------------------------------------------------
The initial clone may be time-consuming for a large project, but you
will only need to clone once.
The clone command creates a new directory named after the project
(`git` or `linux` in the examples above). After you cd into this
directory, you will see that it contains a copy of the project files,
called the <<def_working_tree,working tree>>, together with a special
top-level directory named `.git`, which contains all the information
about the history of the project.
[[how-to-check-out]]
How to check out a different version of a project
-------------------------------------------------
Git is best thought of as a tool for storing the history of a collection
of files. It stores the history as a compressed collection of
interrelated snapshots of the project's contents. In Git each such
version is called a <<def_commit,commit>>.
Those snapshots aren't necessarily all arranged in a single line from
oldest to newest; instead, work may simultaneously proceed along
parallel lines of development, called <<def_branch,branches>>, which may
merge and diverge.
A single Git repository can track development on multiple branches. It
does this by keeping a list of <<def_head,heads>> which reference the
latest commit on each branch; the linkgit:git-branch[1] command shows
you the list of branch heads:
------------------------------------------------
$ git branch
* master
------------------------------------------------
A freshly cloned repository contains a single branch head, by default
named "master", with the working directory initialized to the state of
the project referred to by that branch head.
Most projects also use <<def_tag,tags>>. Tags, like heads, are
references into the project's history, and can be listed using the
linkgit:git-tag[1] command:
------------------------------------------------
$ git tag -l
v2.6.11
v2.6.11-tree
v2.6.12
v2.6.12-rc2
v2.6.12-rc3
v2.6.12-rc4
v2.6.12-rc5
v2.6.12-rc6
v2.6.13
...
------------------------------------------------
Tags are expected to always point at the same version of a project,
while heads are expected to advance as development progresses.
Create a new branch head pointing to one of these versions and check it
out using linkgit:git-checkout[1]:
------------------------------------------------
$ git checkout -b new v2.6.13
------------------------------------------------
The working directory then reflects the contents that the project had
when it was tagged v2.6.13, and linkgit:git-branch[1] shows two
branches, with an asterisk marking the currently checked-out branch:
------------------------------------------------
$ git branch
master
* new
------------------------------------------------
If you decide that you'd rather see version 2.6.17, you can modify
the current branch to point at v2.6.17 instead, with
------------------------------------------------
$ git reset --hard v2.6.17
------------------------------------------------
Note that if the current branch head was your only reference to a
particular point in history, then resetting that branch may leave you
with no way to find the history it used to point to; so use this command
carefully.
[[understanding-commits]]
Understanding History: Commits
------------------------------
Every change in the history of a project is represented by a commit.
The linkgit:git-show[1] command shows the most recent commit on the
current branch:
------------------------------------------------
$ git show
commit 17cf781661e6d38f737f15f53ab552f1e95960d7
Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)>
Date: Tue Apr 19 14:11:06 2005 -0700
Remove duplicate getenv(DB_ENVIRONMENT) call
Noted by Tony Luck.
diff --git a/init-db.c b/init-db.c
index 65898fa..b002dc6 100644
--- a/init-db.c
+++ b/init-db.c
@@ -7,7 +7,7 @@
int main(int argc, char **argv)
{
- char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
+ char *sha1_dir, *path;
int len, i;
if (mkdir(".git", 0755) < 0) {
------------------------------------------------
As you can see, a commit shows who made the latest change, what they
did, and why.
Every commit has a 40-hexdigit id, sometimes called the "object name" or the
"SHA-1 id", shown on the first line of the `git show` output. You can usually
refer to a commit by a shorter name, such as a tag or a branch name, but this
longer name can also be useful. Most importantly, it is a globally unique
name for this commit: so if you tell somebody else the object name (for
example in email), then you are guaranteed that name will refer to the same
commit in their repository that it does in yours (assuming their repository
has that commit at all). Since the object name is computed as a hash over the
contents of the commit, you are guaranteed that the commit can never change
without its name also changing.
In fact, in <<git-concepts>> we shall see that everything stored in Git
history, including file data and directory contents, is stored in an object
with a name that is a hash of its contents.
[[understanding-reachability]]
Understanding history: commits, parents, and reachability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Every commit (except the very first commit in a project) also has a
parent commit which shows what happened before this commit.
Following the chain of parents will eventually take you back to the
beginning of the project.
However, the commits do not form a simple list; Git allows lines of
development to diverge and then reconverge, and the point where two
lines of development reconverge is called a "merge". The commit
representing a merge can therefore have more than one parent, with
each parent representing the most recent commit on one of the lines
of development leading to that point.
The best way to see how this works is using the linkgit:gitk[1]
command; running gitk now on a Git repository and looking for merge
commits will help unders
没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
收起资源包目录
git-2.9.0源码包 (2000个子文件)
diff.0-1 49B
diff.0-2 77B
diff.0-3 80B
LGPL-2.1 26KB
diff.1-0 49B
diff.1-2 80B
diff.1-3 80B
diff.2-0 77B
diff.2-1 80B
diff.2-3 77B
diff.3-0 80B
diff.3-1 80B
diff.3-2 77B
a,v 2KB
a,v 589B
configure.ac 35KB
add-comments 88B
add-content 47B
add-content-and-comment 73B
add-signed-off 63B
add-whitespaced-content 76B
am-test-1-1 312B
am-test-1-2 315B
am-test-2-1 330B
am-test-2-2 333B
am-test-3-1 350B
am-test-3-2 340B
diff.c 139KB
regexec.c 125KB
apply.c 119KB
regcomp.c 109KB
files-backend.c 93KB
revision.c 91KB
sha1_file.c 91KB
fast-import.c 88KB
blame.c 77KB
pack-objects.c 72KB
dir.c 70KB
read-cache.c 62KB
am.c 60KB
remote.c 58KB
mingw.c 58KB
merge-recursive.c 58KB
config.c 57KB
commit.c 53KB
http.c 52KB
unpack-trees.c 51KB
http-push.c 50KB
log.c 49KB
wt-status.c 48KB
regex_internal.c 47KB
index-pack.c 46KB
receive-pack.c 45KB
ref-filter.c 44KB
pretty.c 44KB
merge.c 44KB
remote.c 44KB
grep.c 41KB
commit.c 41KB
combine-diff.c 40KB
sha1_name.c 37KB
notes.c 37KB
imap-send.c 36KB
checkout.c 36KB
transport-helper.c 35KB
fetch.c 34KB
graph.c 34KB
convert.c 32KB
submodule.c 32KB
sequencer.c 32KB
daemon.c 31KB
rerere.c 31KB
update-index.c 31KB
line-log.c 31KB
clone.c 30KB
path.c 29KB
refs.c 29KB
transport.c 29KB
notes.c 28KB
setup.c 27KB
fast-export.c 27KB
date.c 27KB
fetch-pack.c 27KB
tree-walk.c 27KB
pull.c 26KB
remote-curl.c 26KB
run-command.c 26KB
branch.c 25KB
pack-bitmap.c 25KB
nedmalloc.c 25KB
bisect.c 25KB
grep.c 24KB
log-tree.c 24KB
clean.c 24KB
mailinfo.c 23KB
submodule--helper.c 23KB
notes-merge.c 23KB
show-branch.c 23KB
trailer.c 23KB
fsck.c 22KB
共 2000 条
- 1
- 2
- 3
- 4
- 5
- 6
- 20
资源评论
Huazie
- 粉丝: 1w+
- 资源: 29
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功