一、Git的基本概念和流程

下图就是一个经典的git基本流程图。

Workspace：这里是我们的工作区，平时我们写完代码，点击保存，存储的就是这个区域。

Index：这里是暂存区，通过 git add xxx 就可以将代码推送到暂存区。它更像是虚拟的工作区，在我们项目下有一个.git的隐藏文件夹，每当我们执行完 git add 命令时都会在 objects 文件夹下面创建一条目录，并且会更新index 文件的索引，指向新生成的objects目录下的文件。

Repository：可以理解为本地仓库，通过 git commit 指令就会将代码提交到本地的仓库。

Remote：远端仓库，通过 git push 可以将本地仓库的代码提交到远端仓库，这样别人就可以将你的代码拉下来查看。

二、常用的基本指令

还未提交的修改内容以及新添加的文件，留在索引区域或工作树的情况下切换到其他的分支时，修改内容会从原来的分支移动到目标分支。
但是如果在checkout的目标分支中相同的文件也有修改，checkout会失败的。

git commit -d myBranch 删除myBranch分支，只能在其他分支上操作，不能当前分支删除当前分支。

git fetch 只是获取远端仓库的最新历史记录。
git pull 则是拉取当前分支的历史记录，这时，如果没有冲突的修改，就会自动创建合并提交。如果发生冲突的话，要先解决冲突，再手动提交。
git pull 实际是先执行git fetch，再执行git merge。

二、场景应用

1、开始一个新的项目

一般新的项目的仓库已经是提前创建好的

git clone '仓库地址'                      克隆到本地（此时在master分支上）
git checkout -b feature_orderlist_cx     新建并切换到自己的功能分支

或者

git branch feature_orderlist_cx       创建自己的功能分支
git checkout feature_orderlist_cx     切换到功能分支上

2、提交代码

git add files 或者 git add .            （所有改动的文件）添加到索引
git commit -m ""
# 或者（以上两部用以下指令代替）
git commit -a -m ""                     提交多有改动的文件，并新增一个提交记录
git pull origin develop                 拉取远端develop分支代码，并合并
# 如果有冲突，解决冲突，再add和commit
git push                                推送代码到本分支的远端分支

冲突时，===== 分割线上方是本地仓库的内容，下方是远程仓库的内容

3、临时暂停当前开发，修改或调试其他代码，弄完后再回来接着开发

git stash save 'some message'   暂时保存现状的操作
# 做其他的代码修改，做完后
git stash list                  罗列暂存的列表
git stash pop                   恢复最近一个暂存
git stash pop stash{0}          恢复指定的暂存

4、合并分支

git checkout develop                      切换到目标分支
git merge feature_orderlist_cx            合并 feature_orderlist_cx 分支到本分支
# 如果有冲突的话，解决冲突，再add和commit
git push

冲突时，===== 分割线上方是本地仓库的内容，下方是远程仓库的内容

5、撤销上一次的提交

git revert HEAD                 会撤销上次的提交，并产生一个revert提交记录
# 或者
git reset 498572d7739d523f6     重置到498572d7739d523f6提交
# 或者
git reset HEAD~                 重置到头一次的提交，抛弃现有的提交

Git revert 会产生一个revert提交记录，git reset 不会

HEAD~ 表示当前记录的前一个记录，HEAD~~ 表示当前记录的前两个记录

6、修改最近一次的提交

git commit --amend    补上漏掉的代码，然后提交，会与最后一次提交合并成一个新的提交记录

三、GitFlow工作流

1、什么是 git flow

是一些扩展命令
不是来替代Git的
可以非常聪明有效地把Git命令用脚本组合起来
自动执行，形成工作流

2、分支模型

Gitflow流程就是围绕这两个特点鲜明的分支展开的。

master分支

上线的分支，稳定的代码

develop分支

新的功能开发的基础分支，也是汇集所有已完成功能

上面两个分支被称为长期分支，存在于项目的整个生命周期中，其他分支，是临时性的，根据需要来创建，当完成了自己的任务后，就会被删掉。

feature分支

平常的开发工作使用最频繁的分支。每一个新功能的开发都应该各自使用独立的分支

在创建新的功能开发分支时，父分支应该选择develop（而不是master）

当功能开发完成时，改动的代码应该被合并（merge）到develop分支

功能开发永远不应该直接牵扯到master

开始一个feature分支

如下命令会创建一个名为”feature/” 的功能分支，该分支默认从 develop检出，在做功能性开发的时候，检出一个独立的分支，是版本控制中一个重要的原则。

完成一个feature分支

该命令会把我们在当前分支的代码整合到‘develop’分支中去，之后，git-flow 会进行清理操作，删除当下完成的功能分支，将分支切换到‘develop’。

release分支

这个分支的创建意味着一个发布周期的开始，也意味着本次发布不会再增加新的功能——在这个分支上只能修复bug，做一些文档工作或者跟发布相关的任务。

在一切准备就绪的时候，这个分支会被合并入master，并且用版本号打上标签。

在发布周期内，分支上的改动还应该合并入develop分支。

使用专门的一个分支来为发布做准备的好处是，在一个团队忙于当前的发布的同时，另一个团队可以继续为接下来的一次发布开发新功能。

创建一个release分支

完成一个release分支

这个命令会完成如下一系列的操作：

1、首先，git-flow 会拉取远程仓库，以确保目前是最新的版本。

2、然后，release 的内容会被合并到 “master” 和 “develop” 两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码。

3、为便于识别和做历史参考，release 提交会被标记上这个 release 的名字（在我们的例子里是 “1.1.5”）。

4、清理操作，版本分支会被删除，并且回到 “develop”。

hotfix分支

发布后的维护工作或者紧急问题的快速修复也需要使用一个独立的分支。

这是唯一一种可以直接基于master创建的分支。

一旦问题被修复了，所做的改动应该被合并入master和develop分支（或者用于当前发布的分支）。

master上还要使用更新的版本号打好标签。

使用专门的一个分支来为发布做准备的好处是，在一个团队忙于当前的发布的同时，另一个团队可以继续为接下来的一次发布开发新功能。

创建一个hotfix分支

完成一个hotfix分支

这个过程非常类似于发布一个 release 版本：

完成的改动会被合并到 “master” 中，同样也会合并到 “develop” 分支中，这样就可以确保这个错误不会再次出现在下一个 release 中。

这个 hotfix 会被标记起来以便于参考。

这个 hotfix 分支将被删除，然后切换到 “develop” 分支上去。

3、分支模型-总结

分支	描述
master	上线的分支，稳定的代码
develop	新的开发的基础分支，汇集所有已完成功能
feature	开发工作使用最频繁的分支
release	发布版本，不能再添加新的功能，只能修改bug
hotfix	用于修复release中的bug

Git常用指令与GitFlow工作流