git基本知识

Git

Linus为了管理Linux代码库编写的一个开源的分布式版本控制系统，可以有效、高速地实现从很小到非常大的项目的版本管理。

版本控制:是一种在开发的过程中用于管理我们对文件、目录或工程等内容的修改历史，方便查看更改历史记录，备份以便恢复以前的版本的软件工程技术。

优点：分支管理能力更强；运行更快；更安全，系统内任何一台机器出故障都不影响整体项目

Git的本地系统结构

Git将一个工作目录分为工作区和版本库。工作在工作区完成；所谓版本库是一个名为.git的隐藏文件夹，包括很多内容，其中最重要的是stage（暂存区）和第一条分支master，以及指向当前分支的指针HEAD。所有文件都可以从工作区流向分支，也可以从分支流向工作区，这些工作都有相应的命令完成。

Git的分支管理原理

一开始的时候，master分支是一条线，Git用master指向最新的一次提交（最近的一次commit），再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化。从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变

假如我们在dev上的工作完成了，就可以把dev合并到master上。把master指向dev的当前提交，就完成了合并

合并完分支后，可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后就剩下了一条master分支

现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突（比如两次提交的某个文件的某一句被都被修改了，且修改不一样），如果冲突了Git会告诉我们，哪个文件存在冲突，必须手动解决冲突后再提交。再次提交后，master分支和feature1分支变成了下图所示：

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

Git下多人开发的工作模式

多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin 推送自己的修改；

2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

3. 如果合并有冲突，则解决冲突，并在本地提交；

4. 没有冲突或者解决掉冲突后，再用git push origin 推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch –set-upstream-to origin/。