Git用户介绍书.doc

《Git用户介绍书.doc》由会员分享，可在线阅读，更多相关《Git用户介绍书.doc（143页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、| Git 用户手册（1.5.3 及后续版 本适用） 翻译: 罗峥嵘 (Robin Steven) 英文版本: http:/www.kernel.org/pub/software/scm/git/docs/user- manual.html Contents 1. Preface 前言 2. Chapter 1. Repositories and Branches 第一章. 版本库与分支 1. How to get a git repository 如何获取一个版本库 2. How to check out a different version of a project 如何提取项目的不同版

2、本 3. Understanding History: Commits 理解历史： 交付 1. Understanding history: commits, parents, and reachability 交付，父交付与可及性 2. Understanding history: History diagrams 历史沿革示图 3. Understanding history: What is a branch? 理解历史：什么是分支 4. Manipulating branches 操作分支 5. Examining an old version without creating a n

3、ew branch 不通过创建新分支来调查旧版本 6. Examining branches from a remote repository 调查远程版本库上的分支 7. Naming branches, tags, and other references 命名分支，标签，与其他引用 8. Updating a repository with git-fetch 用 git fetch 更新版本库 9. Fetching branches from other repositories 获取其他版本库的分支 3. Chapter 2. Exploring git history 第二章.

4、检索 git 历史 1. How to use bisect to find a regression 如何用平分来定位撤退 2. Naming commits 交付的称谓 3. Creating tags 创建标签 4. Browsing revisions 浏览修订 5. Generating diffs 生成差异 6. Viewing old file versions 查看旧的文件版本 7. Examples 实例 1. Counting the number of commits on a branch 统计一个分支中的交付数目 2. Check whether two branch

5、es point at the same history 检查两分支是否在同一历史时期 3. Find first tagged version including a given fix 找到包含给定修正的第一个标签版本 4. Showing commits unique to a given branch 显示仅属于某个分支的交付 5. Creating a changelog and tarball for a software release 为软件的发行制作变更日志和压缩包 6. Finding commits referencing a file with given conten

6、t 寻找一个指向包含给定内容的文件的交 付 4. Chapter 3. Developing with git 第三章. 用 git 进行研发 1. Telling git your name 告诉 git 你的名字 2. Creating a new repository 创建新的版本库 3. How to make a commit 如何制作一个交付 4. Creating good commit messages 写好交付信息 5. Ignoring files 忽略文件 6. How to merge 如何合并 7. Resolving a merge 解决合并冲突 |1. Getti

7、ng conflict-resolution help during a merge 在合并过程中取得冲突解决帮助 8. Undoing a merge 撤销合并 9. Fast-forward merges 快进合并 10. Fixing mistakes 修复失误 1. Fixing a mistake with a new commit 修复一个新的交付中的失误 11. Fixing a mistake by rewriting history 通过重写历史来修复失误 12. Checking out an old version of a file 提取一个文件的旧版本 13. Tem

8、porarily setting aside work in progress 临时放下手头上的工作 14. Ensuring good performance 确保好的性能 15. Ensuring reliability 确保伸缩性 1. Checking the repository for corruption 检查版本的损坏 2. Recovering lost changes 恢复丢失的变更 5. Chapter 4. Sharing development with others 第四章. 与他人协同研发 1. Getting updates with git-pull 用 gi

9、t-pull 取得更新 2. Submitting patches to a project 向项目提交补丁 3. Importing patches to a project 给项目导入补丁 4. Public git repositories 发布 git 版本库 5. Setting up a public repository 建立一个公共版本库 6. Exporting a git repository via the git protocol 通过 git 协议公开版本库 7. Exporting a git repository via http 通过 http 协议公开版本库

10、8. Pushing changes to a public repository 将变更推入到公共版本库 9. What to do when a push fails 推入失败之后该怎么处理 10. Setting up a shared repository 建立共享版本库 11. Allowing web browsing of a repository 容许 Web 浏览版本库 12. Examples 例子 1. Maintaining topic branches for a Linux subsystem maintainer | Linux 子系统维护者如何维护主 题分支 6

11、. Chapter 5. Rewriting history and maintaining patch series 第五章. 改写历史与维护补丁串 1. Creating the perfect patch series 创建出色的补丁串 2. Keeping a patch series up to date using git-rebase 使用 git-rebase 保持补丁串的新颖 3. Rewriting a single commit 重写单个交付 4. Reordering or selecting from a patch series 在补丁串中选取与重新排序 5. Ot

12、her tools 第三方工具 6. Problems with rewriting history 重写历史带来的问题 7. Why bisecting merge commits can be harder than bisecting linear history 为何定位合并交付中的 问题要比在线性历史中困难 7. Chapter 6. Advanced branch management 第六章. 高级分支管理 1. Fetching individual branches 2. git fetch and fast-forwards 抓取与快进 3. Configuring rem

13、ote branches 配置远程分支 8. Chapter 7. Git concepts 第七章. Git 概念 1. The Object Database 对象数据库 1. Commit Object 交付对象 2. Tree Object 树对象 3. Blob Object 片对象 4. Trust 信赖 5. Tag Object 标签对象 6. How git stores objects efficiently: pack files | git 如何高效地储存对象： 打包文件 7. Dangling objects 悬空对象 8. Recovering from repos

14、itory corruption 从损坏中恢复 2. The index 索引 9. Chapter 8. Submodules 子模块 |1. 1. Pitfalls with submodules 子模块陷阱 10. Chapter 9. Low-level git operations 第九章. 底层 git 操作 1. Object access and manipulation 对象访问与操作 2. The Workflow 运作流程 1. working directory - index 工作树 - 索引 2. index - object database 索引 - 对象数据库

15、 3. object database - index 对象数据库 - 索引 4. index - working directory 索引 - 工作目录 5. Tying it all together 全盘了解 3. Examining the data 检验数据 4. Merging multiple trees 合并多个树 5. Merging multiple trees, continued 合并多个树，续完 11. Chapter 10. Hacking git 第十章. git 的开发 1. Object storage format 对象的存储格式 2. A birds-ey

16、e view of Gits source code 鸟瞰 git 源代码 12. Chapter 11. GIT Glossary 第十一章. GIT 字典 13. Appendix A. Git Quick Reference 附录 A. Git 快速参考 1. Creating a new repository 创建一个新的版本库 2. Managing branches 管理分支 3. Exploring history 勘查历史 4. Making changes 制作变更 5. Merging 合并 6. Sharing your changes 共享你的变更 7. Reposit

17、ory maintenance 版本库的维护 8. Appendix B. Notes and todo list for this manual 附录 B. 备忘与本手册的工作计划 Preface 前言 Git is a fast distributed revision control system. Git 是一个快速的分布式版本控制系统 This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of git. 这个手册是

18、面向那些具有基本的 Unix 命令行使用技能，但是没有 Git 知识的人设 计的。 Chapter 1, Repositories and Branches and Chapter 2, Exploring git history explain how to fetch and study a project using gitread these chapters to learn how to build and test a particular version of a software project, search for regressions, and so on. 第一章

19、版本库与分支 和 第二章 考查 git 历史 将展示如何用 git 来获取和研究一个 项目，通过阅读这些章节，我们学习如何建立和测试一个具体的软件项目的版本， 学习“撤退”等等。 |People needing to do actual development will also want to read Chapter 3, Developing with git and Chapter 4, Sharing development with others. 人们是需要开展真正的研发工作的，那么就学习 第三章， 用 git 进行开发 和 第四 章，与他人共享研发成果。 Further cha

20、pters cover more specialized topics. 更多的一些章节会涉及到许多的专题话题。 Comprehensive reference documentation is available through the man pages, or git- help(1) command. For example, for the command “git clone “, you can either use: 参考文档可以通过系统的手册页命令，或者是 git-help(1) 命令来查看。譬如，你想 参考 “git clone “， 你可以用下面的两种方式： $ man

21、git-clone or: 或者： $ git help clone With the latter, you can use the manual viewer of your choice; see git-help(1) for more information. 晚一点你就有机会用到这些手册查看器的；看 git-help(1) 会得到比较多的信息。 See also Appendix A, Git Quick Reference for a brief overview of git commands, without any explanation. 阅读 附录 A，那里是一个 gi

22、t 命令的快速纵览，但是它不带任何的解说。 Finally, see Appendix B, Notes and todo list for this manual for ways that you can help make this manual more complete. 最后，看看 附录 B，这份手册的工作备忘和计划，通过它你可以帮助这份文档变 得更完善。 Chapter 1. Repositories and Branches 第 一章. 版本库与分支|How to get a git repository 如何获取一个版本库 It will be useful to have

23、a git repository to experiment with as you read this manual. 有一个实验性的 git 版本库对我们阅读这份手册将非常有用。 The best way to get one is by using the git-clone(1) command to download a copy of an existing repository. If you dont already have a project in mind, here are some interesting examples: 获取一个已经存在的版本库，最佳的方法是用

24、git-clone 命令，如果你还没有什么 心目中的项目的话，那么这里有些有趣的例子： # git itself (approx. 10MB download): $ git clone git:/git.kernel.org/pub/scm/git/git.git# the Linux kernel (approx. 150MB download): $ git clone git:/git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git The initial clone may be time-consuming fo

25、r 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-2.6“ in the examples above). After you cd into this directory, you will see that it contains a copy of the project files, cal

26、led the working tree, together with a special top-level directory named “.git“, which contains all the information about the history of the project. 克隆命令会创建一个新的目录，并根据项目的名称来命名这个项目（譬如上说例子 中的 “git” 和 “linux-2.6”）。当你进入这个目录的时候，你可以看到它已经包含了 项目的所有文件，我们称之为工作树，在顶层目录中还连带了一个叫 “.git“ 的特殊 的目录，里面包含了项目的发展历史的所有信息。 H

27、ow 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 projects contents. In git each such version is called a commit. 最好将 git 当

28、作是文件发展的历史纪录的收集工具，它压缩并保存了项目的发展的 关联性快照。在 git 中，每个这些变更称作交付(commit)。 |Those snapshots arent necessarily all arranged in a single line from oldest to newest; instead, work may simultaneously proceed along parallel lines of development, called branches, which may merge and diverge. 这些快照并不需要按从旧到新单线索地发展；它可以

29、是同步并行地发展的，称之为 分支，它们是可以合并和分割的。 A single git repository can track development on multiple branches. It does this by keeping a list of heads which reference the latest commit on each branch; the git-branch(1) command shows you the list of branch heads: 一个 git 版本库可以跟踪多个分支的发展，它通过保存一个分支头列表的方式来做 到这一点，每个分支头

30、都是一个引用(reference)，它指向该分支最后的一个交付 (commit)； git-branch(1) 命令可以向你展示每个分支头： $ 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. 一个刚刚克隆的版本库只包含一个分支头，默认

31、叫 “master” （主分支），并且工 作目录已经被初始化为这个分支头所指向的项目状态。 Most projects also use tags. Tags, like heads, are references into the projects history, and can be listed using the git-tag(1) command: 大部分的项目还用到标签（tags）。标签（Tags ）就好像头（heads），它指向项目 的某个历史场面，它们可以通过 git-tag(1) 命令列举出来： $ git tag -l v2.6.11 v2.6.11-tree v2.6

32、.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. |Tags 被当做是项目统一的版本来对待，而 heads 则是项目前进的每一个步伐。 Create a new branch head pointing to one of these ve

33、rsions and check it out using git- checkout(1): 下面创建一个新的分支头，使其指向其中的某个版本，同时将它提取出来，可以用 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 git-branch(1) shows two branches, with an asterisk marking the

34、currently checked-out branch: 工作目录将被镜像为项目中标记为 v2.6.13 的版本的内容，用 git-branch(1) 命令展 示这个两个分支，前面带星号(*)的就是当前抽取的分支。 $ git branchmaster * new If you decide that youd rather see version 2.6.17, you can modify the current branch to point at v2.6.17 instead, with 如果你打算看看 2.6.17 的版本，你可以迁移你当前的分支，让它指向 2.6.17, 使用

35、一下命令： $ 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. 注意，如果当前的分支头是你唯一的指向具体的历史场面的引用的话，那么复位 (resetting)

36、这个分支将令你无法找回这个分支以前的所有历史纪录，所以这个命令 要慎用。 Understanding History: Commits 理解历史： 交付 Every change in the history of a project is represented by a commit. The git-show(1) command shows the most recent commit on the current branch: |项目的每一个历史变更体现为每一个交付 (commit)。git-show(1) 命令展示当前分支 的最新交付： $ git show commit 17c

37、f781661e6d38f737f15f53ab552f1e95960d7 Author: Linus Torvalds Date: Tue Apr 19 14:11:06 2005 -0700Remove duplicate getenv(DB_ENVIRONMENT) callNoted 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

38、*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 “

39、SHA1 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

40、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 c

41、hange without its name also changing. 每个交付都有一个 40 个 16 进制字符的标识号，称为 “对象名” 或者叫 “SHA1 id”， 它显示在 git-show 命令的输出的第一行中。你通常可以用较简短的名字来指明一个 交付，譬如标签和分支的名称等等，但是这个长长的名字是很有用的。最重要的是， 对于某个交付来说它是全局唯一的名字： 譬如你告诉其他人某个对象名（通过 email 等方式），那么你需要确保这个名字不管是在你的版本库中，还是在他们的 版本库中都是指向同一个交付的（假设他们的版本库也被提交了很多东西）。当对 象名根据每个交付的内容通过哈希算法（

42、hash）算出之后，你就可以确保每个交付 中的内容的修改都不可能脱离它的名字。 |In fact, in Chapter 7, 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. 事实上，在 第七章，Git 的概念 中，我们可以看到保存在 git 历史中的所有东西， 包括文件数据与目录内容都会被保存

43、为对象，对象名就是他们的内容的哈希特征值。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

44、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 m

45、erge 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. 无论如何，这些交付的组织形式都不会是简单的；git 容许开发路线可以分道扬镳， 也可以殊途同归，两条开发线路的结合点我们叫“合并” （merge）。表示合并的交 付就等于有一个以上的父交付了，每个父交付表示每个开发线路发展到这里的最贴 近的交付。 The best way to see

46、 how this works is using the gitk(1) command; running gitk now on a git repository and looking for merge commits will help understand how the git organizes history. 最好的查看这个机制的方法是用 gitk(1) 命令；现在在版本库中运行 gitk 命令，并 查看一下那些合并交付会对你理解 git 是如何组织历史的很有帮助。 In the following, we say that commit X is “reachable“ f

47、rom commit Y if commit X is an ancestor of commit Y. Equivalently, you could say that Y is a descendant of X, or that there is a chain of parents leading from commit Y to commit X. 接着，我们说 交付 X 对于 交付 Y 来说是“ 可及的” ， 如果 交付 X 是 交付 Y 的祖 先的话。同样地，你可以说 Y 是 X 的一个后裔， 或者说存在一个从 Y 追索到 X 的世系族谱。 |Understanding hist

48、ory: History diagrams 历史沿革示图 We will sometimes represent git history using diagrams like the one below. Commits are shown as “o“, and the links between them with lines drawn with - / and . Time goes left to right: 某些时候，我们会用下面的示图来描述 git 的历史。所有的交付用 “o“ 表示， 联系 他们各个发展线路之间画上 / 和 。时间的推移是由左至右。 o-o-o - Bran

49、ch A/o-o-o - mastero-o-o - Branch B If we need to talk about a particular commit, the character “o“ may be replaced with another letter or number. 如果需要具体地谈论某个交付，那么就用其他的字母或者是数字来替代 “o“ 。 Understanding history: What is a branch? 理解历史：什么是分支 When we need to be precise, we will use the word “branch“ to mean a line of d