git 管理个人文档，秉承学以致用、用以促学，应用到文档备份。

凡需持续变动的文档皆可作为项目并将会于git进行管理，可详细记录对于项目的各种修改，提供了文本分析工具。

基于现有文档建立项目仓库

初始化git仓库：
$ cd $work
$ git init

$work 也变成了工作树
在$work 目录下创建了一个 .git 隐藏目录，它就是所谓的 git 仓库，不过现在它还是空的。

下面应当有选择地将工作树中的一些文档存储到 git 仓库中。
要进行一秋处理，生成git仓库所能接受的数据格式，生成快照,将工作树下所有文档（包含子目录）生成快照，彩命令：
$ cd $work
$ git add

所生成的快照被存放到一个临时的存储区域，称索引，使用 git commit 可将索引提交到仓库中，这个过程为提交，每一次提交意味着版本在进行一次更新
执行命令时，会自动调用系统默认的文本编辑器，要求你输入版本更新说明并保存。
可以使用 $ git commit -m "你的重酬更新信息"

看过上一节内容，也许你会跃跃欲试，准备拿自己的一个文档目录下手。为了概念的完整性，省略了两个细节问题。
问题1，要地汶每个人在向仓库提交灵数据时，都应当承担一定的责任，自我介绍：
$ git config --gobal user.name "Your Name "
$ git config --global user.email you@youdomain.example.com

工作树中有一些文档是你不希望接受git管理的，譬如程序编译时生成的中间文件，
工作树 zh 目录存放着编译时生成的中间文件，提供了文档忽略机制，可将你不希望热爱git管理的文档信息写到同一目录下的 .gitignore 文件中。
彩如下操作可将其排除仓库之外，然后再对 $work 生成快照即可
$ cd $work
$ echo "zh" >.gitignore
$ git add

有关 gitignore 文件的诸多细节可阅读其使用手册
$ man gitignore

仓库与工作树

git 仓库就是那个 .git目录，存放的是我们所提交的文档索引内容，git 可基于文档索引内容对其所管理的文档进行内容追踪，从而管理文档的版本控制。工作树是包含 .git 的目录，在前文示例中即 $work 目录。

为了更明确仓库与工作树的概念，下面做一个实验：

$ cp -R $work/.git /tmp/m2doc.git
$ cd /tmp
$ git clone m2doc.git m2doc-copy

首先，将 $work 目录中的 .git 目录中的 .git 目录复制到 /tmp 目录下并进行重命名为 m2doc.git
然后使用 git-clone 命令从 m2doc.git 中生成 m2doc-copy 目录，若进入 m2doc-copy 目录观察一下，就会发现该目录所包含的内容是等同于 $work 目录的。
意味着，只要我们拥有仓库，即m2doc.git ，那么就可以很容易地生成工作树，而这个工作树又包含着一个仓库，即 m2doc-copy 目录观察一下，就会发现该目录所包含的内容是等同于 $work 目录的。
意味着，只要拥有仓库，即 m2doc.git ，那么就可以很容易地生成工作树，而这个工作树又包含着一个仓库，即 m2doc-copy/.git 可以这样理解，在 git 中，仓库与工作树之用无需分的很清楚。

在项目中工作，无非对所管理的文档进行修改等，引操作与彩git管理之前没有任何差异，只是在你认为一个工作阶段完成之时，要刻通知git，命令它记下你所进行更新，这一步骤是通过生成文档快照并将基加入到索引中来实现的。

譬如今天，我向 $work 目录添加了一份新文档 ch1.tex ，我需要通知 git 记住我的这一更新
$ cd $work
$ git add ch1.tex

这样，git 就会将有关 ch1.tex 的更新添加到索引中，又修改其它文档， doc-env.tex 、 git-tutor.tex 文件，继续使用 git-add 命令将它们的更新添加到索引中
$ git add doc-env.tex git-tutor.tex

晚上，这一天的工作告一段落。我觉得有必要将今天所做的提交到仓库中，于是执行 git-commit 操作，将索引内容添加到仓库中。
一天下来，许多文档都进行了更新，但是忘记了它们的名字
做法就是：
$ cd $work
$ git add
$ git commit -a
...输入日志信息...

git-add 能够判断出当前目录（包括其子目录）下用户所添加的新文档，并将其信息追加到索引中。
-a选项 可将所有被瞩的、已删除的文档的当前太太提交到仓库中。如果只是修改或者删除了已被 git 管理的文档，
是没必要使用 git-add 命令的。

并未计棕亲的 git 命令，完全是前面所讲过的一些命令的重复介绍，只是它们出现的场景有所区别而已。
git 不会主动记录你对文档进行的更新，除非你对它发号施令。

查看当前项目的日志
$ git log
想看一下每一次版本的大致变动情况，可使用：
$ git log --stat --summary

将项目版本号用作 git-show 命令的参数，即可查看更新细节
也不可以使用以下方式
$ git show dfb02 #一般只使用版本号的前几个字符即可
$ git show HEAD #显示当前分支的最新版本的更新细节

可使用如下命令查看当前项目重酬的父版本更新细节
$ git show HEAD^
$ git show HEAD^^
$ GIT SHOW HEAD~4 祖父之祖父更新细节

可以对荐版本号进行自定义，可以用之查对应的项目版本更新细节
$ git tag v0.1 dfb02
$ git show

上术并非真正进行了版本号自定义，只是制造了一个 tag 对象而已，在对外发布时比罗有用。本文档后续章节会对tag的一些细节进行介绍。

版本控制系统的一个重要任务就是撤销和恢复。git-reset 命令就是为这样的任务而准备的。
git-reset 有三个选项：--mixed、--soft 和 --hard。
第3表杀伤力太大
--mixed 是默认选项，作用是梨园索引内容，定位到指定的项目版本，而不改变你的工作树中的所有内容，只是提示你有哪些文件还未更新

--soft 既不触动索引的位置，也不改变工作树中的任何内容，但是会要求它们处于一个良好的次序之内。会保留你在工作树中的所有更新并使之处于待提交状态。

具体使用可鲜为人知本章的练习题，如果欲查看 git-reset 命令对工作树的影响，可使用 git-status 命令。

如何使用 git 帮助文档
在正文中，总是使用类似 git-reset 这样的命令形式，在终端中实际输入这些指令时，所彩的命令形式又变为git reset。
我猜测这样做的原因是后者作为命令形式对于用户更为友好一些，但查阅时
$ man git-reset

总结
现在总算是掌握了有关git的一些粗江但非常实用的知识，已具备了使用git管理个人文档的能力，希望大家能积极地使用git来管理你认为需要进行版本控制的个人文档。

化解多人协同动作过程中出现的各种矛盾是推广git 应用的主要原因。

两个人如何协同
Lyr 与 Tzc 是要邢的两们主角。开始着手开发
工作树为 /work/m2ge 后者可通过以下命令获得与之同样的工作树
$ cd work
$ git clone lyr@192.168.0.7:~/work/m2ge m2ge

git-clone 可利用网络协议访问远端机器中的 git 仓库，从中导出完整的工作树到本地
通过 SSH 协议访问了 Lyr机器上的 lyr 账户的 m2ge 仓库并进行导出，从而在当前目录下建立了 m2ge 工作树。m2ge 默认同名的工作树名，此处多余。

一个阶段之后，二人均将所做的工作不断地提交到各自的git仓库中，直到他们觉得有必要将各自所做的工作合并起来之后再进行新的开发阶段。

$ cd ~/work/m2ge
$ git pull tzc@192.168.0.5:~/work/m2ge
git-pull 可将属于同一项目的远端仓库与同样属于同一项目的本地仓库进行合并，包含了两个操作：从远端仓库中取出更新版本，然后合并到本地仓库。
如果 是对不同的文件进行了改动，可以不费周折地完成仓库合并但是倘若二人对一些相同的文件进行了改动，那么在合并时必然会

<<<<<<< HEAD:foo
ONE
=================
one ONE
>>>>>>>>>>>>>>>>1111

以一串 〈 形状的字串表示 Lyr 的当前项目版本对 foo.txt 的修改结果，而以一串 > 形状的字串表示 Tzc 的当前项目版本对 foo.txt 的修改结果。中间用了一串 = 号将二人修改结果隔开。一量理解了重酬冲突的表示格式。将合并处理结果提交到仓库中，即完成了重叠冲突的合并问题的解决。

git-pushi 可将本地版本更新摄像头到远端仓库中
其余三个项目开发流程如下

$ git cloe lyr@192.18.0.7:~/work/m2ge
....项目开发....
$ git add 改动的文件
$ git commit
$ git pull
....解决版本合并问题...
$ git push

在一个协同周期内，Lyr 对m2ge仓库的管理工作相当于管理一份他个人荐一般，因为 m2ge 库是位于他的机器上，他是不需要 git-pull

m2ge 的协同开发
通过 SSH 登录到服务器，寻找合适位置，建立m2ge.git 目录，譬如 /project m2ge.git
然后初始化一个空仓库
$ mkdir -p ~/project/m2ge.git
$ cd ~/project/mwge.git
$ git --bare init --shared

--bare 选项让 m2ge.git 目录等价于一个仓库。将本应当存放在 m2ge.git/.git 中的仓库内容全部放置在 m2ge.git 目录下，就好像仓库完全的裸露在工作树中。

将之推送
$ cd ~/work/m2ge
$ git push m2@192.168.0.2:~/project/m2ge.git master

已经得到了 m2g 仓库的最初版本，并且可以使用 git-clone 命令在本地创建工作目录
$ git clone m2@192.168.0.2:~/project/m2ge.git
之后，我人就可以开始一个又一个协同周期，服务器上的m2ge.git仓库将会逐次记录着。

足以实现 m2ge 初级阶段的协同开发。

项目分支管理

较为流行的，虽然也提供了项目分支管理，但是可用性极低。
管理多个荐分支如探囊取物耳。

如何产生项目分支
前面是有一个分支存在的，master 分支（主分支），该分支是由git自动产生的。在此之前，我们针对项目版本的各种操作都是在主分支上进行的，只是我们示察觉它的存在。
git 可以轻松地产生新的项目分支
$ git branch local

初始时完全等同于主分支的，在其上进行的所有版本更新工作都不影响主分支，这意味着作为项目的参与者，可以在local中开始各种各样的更新尝试。
查看项目仓库中存在多少分支，可直接使用 git-branch
$ git branch
local
*master
* 符号，表示此分支为当前分支，

不会自动切换到 local 下，可使用 git-checkout 命令实现分支切换$ git checkout local

分支的合并
在local 分支，进行了诸多修改与数次版本更新提交，如何将这一分支的最终状态提交到 master 分支中呢？
git-merge 可实现丙个分支的合并
$ git checkout master #
$ git merge local

当一个分支检查无误并且与 master 分支成功合并完毕后，那么这一分支基本上就没有存在必要性了，可以删除掉。
$ git branch -d local

对于未有合并的分支是无法删除的，如想强制删除，可以使用 git-branch 的 -D 选项

m2ge 新的协同开发模式

看一看围绕mwge 开发工作的一天中的工作过程
首先，更新自己机器上的工作树，并查看实验室其他成员的版本更新信息
$ git pull
$ git log

开始建立一个新的项目分支，命名为 lyr，并将当前分支切换为该分支

$ git branch lyr
$ git checkout lyr

一天中第八的大部分时间
$ git checkout
$ git merge lyr
$ git branch -d lyr
已经将这一天的工作反题到自己机器上的m2ge mater 分支上了，将其推磅到服务器的 m2ge 仓库。操作之前，需要使用 git0pull 将这一天中其他成员对服务器端的 m2ge 的更新接过来合并到自己的 master 分支，然后才可以将自己的版本更新推送到服务器上的 mwge 仓库

好处：有效保持了要地项目主分支的干净，避免了肯第 git-clone 服务器端的 m2ge 仓库来恢复本地项目主分支