git使用过程版本详解
一、什么是版本控制系统(Version Control System - VCS)
分布式 VCS (Distributed VCS / DVCS)和中央式的区别在于，分布式版本控制系 统除 中央仓库外，还有本地仓库，团队内所有成员都有 份 的本地仓库，本 地仓库在与中央仓库的交互中，会 拷 份完整的版本信息， 需联 ，我们 就可以完成版本的控制，只是中间多 步本地仓库的操作，在分布式版本控制系 统中，中央系统起到的作 只有同步成员间版本信息的 个作 。
作流程
- 主程在本地仓库提交初始代码
- 服务 创建远程仓库，并推送到远程仓库
- 团队内成员clone中央仓库
- 后期团队内的每 步操作，都要先提交到本地仓库，然后推送到中央仓库
- 团队内其他成员在看到有新的变 的时候，需要把远程仓库的提交同步到本地 仓库，并与本地代码合并
二、git的使用
1.git的安装
使 mac的同学， 般都会 带git命令，没有安装的同学可以 在此下载 或者使 homebrew安装
2.git的基本使用
我们在演示的时候是在github创建 个测试仓库
先我们需要把远程仓库clone到本地
git clone git地址
可以看到我们的远程仓库已经下载到本地
在Finder中我们查看我们的 件可以看到除 我们的 README.md 外还有 个隐藏属 性的 .git 件夹
这个 .git 录，就是你的本地仓库(Local Repository)，你的所有版本信息都 会存在这 。 .git 所在的这个根 录，称为 Git 的 作 录(Working Directory)，它保存 你当前从仓库中签出(checkout)的内容。现在你在项目的目录下命令行输入 :
git log
会得到版本号等详细信息，如下图：
3.第一次提交
* 先我们在目录下创建一个新的文件 test.txt
* 然后我们要查看当前的工作目录的状态
git status
注： status 用来查看当前工作目录状态的指令
* 对于当前 test.txt 件的状态是 Untracked (未被跟踪状态的)，现在我们使 git commit 是提交不上去的，我们在查看提交记录也是看不到当前文件的，如果想提交这个文件 ，首先我们要在版本控制系统中跟踪这个文件，使 用add 命令
git add test.txt
执行该命令后，我们再次输入 git status跟踪查看状态
这时可以看到， test.txt 的文件名字变成了绿色字体 ，它的前面多了 「new file:」 的标记， 并且它的描述也从 "Untracked files" 变成 "Changes to be commited"。这些都说明了一点: test.txt 这个 件的状态从 "untracked"(未跟踪)状态变成 "staged"(已暂存)，意思是这个文件中被改动的部分(也就是这整个文件啦)被记录进了 staging area(暂存区)。即提交到了本地暂存区。
* 下面我们就可以把这个文件提交到本地仓库，使用 git commit命令：
git commit
输入这个git commit命令后我们会进入 vim 编辑界面，这个界面是要我们输入本次提交的 描述message ,进入界面后我们我们按下键盘上的 i键 , 我们就进 入编辑的状态，编辑完 成后，按下 esc 退出编辑状态，然后键入 :wq 保存退出
现在我们再次输 git log 可以看到我们刚刚提交的信息:
现在我们再次输 git status ,可以看到没有任何的文件待提交，并且提示我们将使用git push推送所提交的文件到远端master
我们再次进入修改此文件，再次查看状态
处理方式还是和之前一样，先暂存 git add test.txt 这时我们再去查看状态，可以看到已经被暂存 staged ，待提交状态 Changes to be committed
下面就是 git commit -m "change test.txt"
4.推送到远程服务
在上面的操作后，我们看下目前本地的状态
本地仓库已经有三次提交记录
我们再看看中央仓库只有一次版本记录，说明我们本地版本已经领先于中央仓库两次提交
我们可以通过 git status 来看到领先的提交数，在下面的图中我们可以看到已经 领先 两次
* 我们现在需要把我们本地的变更提交到中央仓库
但是在我们推送之前，我们通常会先去拉取中央仓库别人提交的代码，防止代码冲突或者覆盖别人提交的代码git pull，注：有冲突先解决冲突显示我们的已经是最新的代码了
* 然后我们需要把我们已提交的代码推送到远程服务
git push在推送的时候首先我们需要输入账户，密码，输入完成后，可以看到下面的状态提示的推送成功 ，现在我们再去中央仓库看下提交的记录
这时可以看到我们本地的提交已经推送到远程服务了
5.免密推送代码
我们在日常进行提交的时候肯定是不想要每次提交都要求我们输入账号密码，所以 我们就需要配置ssh私钥的方式来免密推送提交记录
7.多人协作 基本使用
先我们在本地再clone一份，这样的话，我们就可以模拟出所有的多人协作的场景 ，如果你对这样的操作有担心 ，大可不必，这种操作不会有任何问题。因为 Git 的管理是目录级别， 而不是设备级别的。也就是说， /gitTest/test 目录内的.git 只管 /gitTest/test 的内容， /gitTest2/test 录内的 .git 也只管 /gitTest2/test 目录的内容，它们之间互不知晓，也互不影响。
8.拉取远程代码
* 下面我们在我们刚刚clone的新的目录内修改测试文件，并提交到远程服务
* 然后我们在我们的目录内进行拉取最新的代码
可以看到有人已经修改了代码
9.冲突解决
先模拟一个冲突吧
10.HEAD、Master、branch
HEAD
HEAD 始终指向当前commit的引用 ，当前commit就是指当前目录对应的 commit 总之，当前 commit 在哪里 ， HEAD 就在哪里，这是一个永远自动指向当前 commit 的引用，所以你永远可以用 HEAD 来操作当前 commit 。
branch
论上说branch也只是git中的一个引用 ，分支可以理解为我们在初始commit到 branch引用的一个串
- 所有的branch都是平等的
- branch包含 初始commit到当前修改的所有的commit， 径之间也是彼此平
等的
master
- 默认创建的分 (主分 )
- gitclone默认checkout(签出)分支
11.删除分支
删除分支必须要把HEAD移动到其他的分支
git branch -d branch-name
如果当前的分支还没有合并进master的分支删除时会失败
下面的命令可以强制删除分支：
git branch -D branch-name
12.merge分支
从目标 commit 和当前 commit (即 HEAD 所指向的 commit)分叉的位置起，把目标 commit 的路径上的所有 commit 的内容一并应用到当前 commit，然后自动生成 一个新的 commit。
13.取消合并分支
git merge --abort
14.Feature Branching
目前团队中版本控制的工具有 SVN 以及 Git ，但是思考一下当前的工作流程和之前有 么区别没?
当前的模式是基于master分支进行所有的版本控制，团队内成员都是通过push到中央仓库的master分支来管理代码，这种工作模式解决了团队协作最基本的需求，事实上，这还是早期的VCS --svn的工作模式，并没有什么区别
这种工作模式的现有问题就是生产环境上出现bug的时候，并不能及时的在master 分支上去进行修改，因为直接在现有的代码上进行修改，是非常不安全的也是不推荐的，现有的最新的代码是我们在测试环境下进行开发的，并没有通过验证，直接进行修改是非常不合理的。 可能有的人会说，我在开发的时候不提交中央仓库， 一直在本地仓库进行修改，可是又会面临如下的问题：
- 没办法在测试环境进 验证
- 团队之间的协作效率会极大的降低，并且在合并的时候会有很多的冲突
下面我就说说对于git的一种主流的版本管理方式
新的工作流程主要如下：
- 任何新的功能都要新建分支 feature-xxx fixBug-xxx 来开发
- 任何分支开发完毕都要合并到 master dev 分支并且删除掉原有的开发分支
1.主分支 (master)
在我们的项目管理中master分支，只负责在我们项目开发中合并已经测试通过的版本，并且master分支最主要的特点就是其版本代码的稳定以及永远是可发布的版本。
2.开发分 (develop)
平时我们的开发都是在dev分支上进行 ，dev分支承载着我们日常开发的所有的分支合并以及在此基础上进行拉新分支进行功能(feature-xx)开发，如果在dev分支上功能趋于稳定可以在此基础上创建预发 (pre-release-xx)版本进行功能测试，在开发以及测试通过后应及时合并到dev分支或者master中，我们应该确保在我们的日常开发中，分支中只有master和dev。
3. 特殊分支
上面说到 dev分支， 一般我们在开发中会有三种状态：
- 开发新功能(feature-xx)
- 预发布测试版本(pre-release-xx)
- 修复bug(fixbug-xx)
* feature 是为 开发某个特定功能，从dev上开此新分支，开发完毕后合并到dev
* pre-release 预发布版本，从dev或者fixbug上开此新分支，测试完毕，必须合并进 master和dev
* fixbug 为了修复线上bug，从master上开此新分支，在修复完毕后，必须合并进 master和dev
一般我们开辟新分支之后，我们需要根据自己是否需要跟别人合作以及是否会在仿真发布来判断是否需要把开辟的新分支推送到远程服务
--amend – 修改上 次commit