【转载】GIT教程 猴子都能懂得git入门
完整官方承认教程
猴子都能懂得git入门
https://backlog.com/git-tutorial/cn/
GIT
入门
GIT与其他的区别
git是一个开源的分布式版本控制系统,用以快速高效的处理项目从很小到非常大的项目的版本控制的所有事情。
直接记录快照，而非差异比较
Git 和其它版本控制系统(包括 Subversion 和近似工具)的主要差别在于 Git 对待数据的方法。 概念上来区分，其它大部分系统以文件变更列表的方式存储信息。 这类系统(CVS、Subversion、Perforce、Bazaar 等等)将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。存储每个文件与初始版本的差异，如下图所示 -
Git 不按照以上方式对待或保存数据。 反之，Git 更像是把数据看作是对小型文件系统的一组快照。 每次你提交更新，或在 Git 中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。如下图所示 -
这是 Git 与几乎所有其它版本控制系统的重要区别。 因此 Git 重新考虑了以前每一代版本控制系统延续下来的诸多方面。 Git 更像是一个小型的文件系统，提供了许多以此为基础构建的超强工具，而不只是一个简单的 VCS。 稍后我们在 Git 分支讨论 Git 分支管理时，将探究这种方式对待数据所能获得的益处。
修改记录的提交
1 系统按时间顺序记录
2 系统通过计算得到40位英文+数字命名用来指定提交文件。
3执行提交时，系统会要求输入提交信息。请务必输入提交信息，因为在空白的状态下执行提交会失败的
共享远程数据库
克隆（clone）
进行克隆（Clone）操作就可以复制远程数据库。
拉取（Pull）
进行拉取(Pull) 操作就可以把远程数据库的内容更新到本地数据
推送（push）
需要在Git执行推送(Push)操作。执行Push之后，本地的修改记录会被上传到远程数据库。所以远程数据库的修改记录就会和本地数据库的修改记录保持同步。
工作树和索引
在数据库和工作树之间有索引，索引是为了向数据库提交作准备的区域
索引区域是用于单独提交文件
不加入索引区域无法提交
高级
什么是分支
分支是为了将修改记录的整体流程分叉保存。分叉后的分支不受其他分支的影响，所以在同一个数据库里可以同时进行多个修改。
分叉的分支可以合并。
为了不受其他开发人员的影响，您可以在主分支上建立自己专用的分支。完成工作后，将自己分支上的修改合并到主分支。因为每一次提交的历史记录都会被保存，所以当发生问题时，定位和修改造成问题的提交就容易多了。
master分支
在数据库进行最初的提交后, Git会创建一个名为master的分支。因此之后的提交，在切换分支之前都会添加到master分支里。
分支的运用
分支分为 Merge分支 和 Topic分支
Merge分支
用于随时发布版本的分支，一般使用master分支当作Merge分支使用，为了版本稳定merge分支不进行修改，而是创建Topic分支进行修改。Merge分支只用于Merge发布稳定版本。
Topic分支
Topic分支是为了开发新功能或修复Bug等任务而建立的分支。若要同时进行多个的任务，请创建多个的Topic分支。
Topic分支是从稳定的Merge分支创建的。完成作业后，要把Topic分支合并回Merge分支
分支的切换
若要切换作业的分支，就要进行checkout操作。进行checkout时，git会从工作树还原向目标分支提交的修改内容。checkout之后的提交记录将被追加到目标分支。
Stash（贮藏）
还未提交的修改内容以及新添加的文件，留在索引区域或工作树的情况下切换到其他的分支时，修改内容会从原来的分支移动到目标分支。
但是如果在checkout的目标分支中相同的文件也有修改，checkout会失败的。这时要么先提交修改内容，要么用stash暂时保存修改内容后再checkout。
stash是临时保存文件修改内容的区域。stash可以暂时保存工作树和索引里还没提交的修改内容，您可以事后再取出暂存的修改，应用到原先的分支或其他的分支上。
HEAD
HEAD指向的是现在使用中的分支的最后一次更新。通常默认指向master分支的最后一次更新。通过移动HEAD，就可以变更使用的分支。
解决冲突
可识别冲突内容
无法识别冲突内容
分支合并
完成作业后的topic分支，最后要合并回merge分支。合并分支有2种方法：使用merge或rebase。使用这2种方法，合并后分支的历史记录会有很大的差别。
Merge
快速合并：是merge没有修改没有冲突 直接合并到当前分支
合并前
合并后
融合合并：master分支如果分叉后修改，要把master分支的修改内容和bugfix分支的修改内容汇合起来。
融合前
融合后
执行合并时，如果设定了non fast-forward选项，即使在能够fast-forward合并的情况下也会生成新的提交并合并。
Rebase（衍合）
rebase方法进行分支合并，会出现下图所显示的历史记录。现在我们来简单地讲解一下合并的流程吧。
合并前
合并后
首先，rebase bugfix分支到master分支, bugfix分支的历史记录会添加在master分支的后面。历史记录成一条线，相当整洁。
Rebase需要解决冲突
rebase之后head的位置不变，需要合并master分支head才会移到bugfix这里
两种方式区别
- merge
保持修改内容的历史记录，但是历史记录会很复杂。 - rebase
历史记录简单，是在原有提交的基础上将差异内容反映进去。
因此，可能导致原本的提交内容无法正常运行。
topic分支和merge分支的运用实例
B版本已经完毕还没打包，需要保存当前状态，开发新功能开新分支（蓝O）开发新功能
开发新功能的时候发现B版本里面有BUG需要修改，在B上面创建新的分支(紫X)
B版本准备打包将修改BUG的X 版本与B版本合并生成C版本
开发新版本是发现之前的BUG影响了新功能需要C版本，将新版本REBASE后继续开发，C版本可继续打包。
Rebase后继续开发。
完整官方承认教程
猴子都能懂得git入门
https://backlog.com/git-tutorial/cn/