常规的Git管理流程

一、前言

Git是目前流行的版本管理工具，大家应该都使用过。虽然Git能为我们的项目管理提供极大的帮助，但是如果使用不当也会造成一些不必要的麻烦，特别是在多人协作的情况下。本文将讲述我们在项目开发中使用的常规Git管理流程。

原文链接: Git: 聊点有用的？

二、Git常规管理流程

1、常用的开发分支

• master 分支 : 主分支，不轻易改动，主要做正式发版使用，一般发版的包都从 master 分支中构建
• pre-release 分支 : 预发布分支，是在正式发版前的测试使用分支，测试使用的包都从此处构建，测试完成后合并到 master 分支进行发版
• developer 分支 : 开发分支，每个版本的所有需求开发所在分支
• feature 分支 : 具体的需求开发分支，因为开发大都是团队协作，开发成员负责自己的需求开发时，一般建议从 developer 分支中重新拉一条分支出来，作为成员自己的开发分支，最后再合并到 developer 分支中，所以 feature 分支一般会有多个
• hotfix 分支 : 紧急修复分支，如果线上版本遇到bug，则一般建议从 master 分支拉出一条分支，作为紧急修复分支，在 hotfix 测试没有问题后，合并到 master 进行紧急发版

2、常用的Git管理流程

从上述常用分支介绍中，我们可以大致了解团队开发时的Git管理流程，此处我们再详细介绍一下常用的管理流程。

Step 1 : 项目创建 master 分支。
Step 2 : 从 master 分支中拉出一条 developer 分支，作为所有的开发需求的汇总分支。
Step 3 : 进行具体的需求开发时，每位开发成员从 developer 分支中拉出一条分支，作为自己的 feature 分支进行具体的需求开发。
Step 4 : 开发完成后的 feature 合并到 developer。
Step 5 : 所有的需求都开发完成后，从 developer 分支中拉出一条 pre-release 分支，提供给 QA 进行测试。不过，有时为了效率，pre-release 分支可能会被省略，直接使用 developer 分支代替。但是如果项目开发时会出现交叉开发，那么个人认为 pre-release 分支的存在还是很重要的。例如本期版本需求还未测试完毕，进行发版，下一期需求就要进行开发，则此时 developer 分支中可能就会混入下期需求代码，那么 pre-release 分支的存在就很有必要了。
Step 6 : 测试完成后，pre-release 分支合并到 master 分支进行发版，并且每次发版都需要打标签，方便后续对历史版本复盘。
Step 7 : 如果线上版本出现紧急bug，则从 master 分支拉出一条 hotfix 分支，对 bug 进行紧急修复，测试完成后将 hotfix 分支合并到 master 进行紧急发版，同时也需合并到 developer 分支。

PS : 所有的远程分支合并，个人建议最好通过 Pull Request (即PR) 来进行。 例如我们要将自己的 feature 分支合并到远程的 developer 分支，可以首先创建一个 PR，然后让其他成员简单的 review 代码的改动，其他同事 approve 后再合并到 developer。使用此种方式，能更有效的追踪代码的改动。

三、必须知道的Git常识

1、Git小常识

Git的三个区域

• 工作区 : 当前的工作区域
• 暂存区 : 被 git add 后的文件所在区域
• 历史记录区 : 已提交历史，git commit 后的提交文件所在区域

Git的三种状态

• 已修改 (modified) : 表示修改了文件，但还没保存到本地仓库中
• 已暂存 (staged) : 表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的暂存区中
• 已提交 (committed) : 表示数据已经安全地保存在本地仓库中

2、Git基本命令

git init : 初始化仓库

在当前目录创建一个Git仓库，如果需要在指定目录创建可以使用 git init [目录]

git add : 添加文件到暂存区

• git add [file1] [file2] ... : 将指定文件添加到暂存区。
• git add [dir] : 将指定目录添加到暂存区。
• git add . : Git 1.x版本时，将新文件 (new) 和被修改 (modified) 文件添加到暂存区，不包括被删除 (deleted) 文件；在Git 2.x版本时，被删除文件也会被添加到暂存区域。
• git add -u (git add --update的缩写) : 将被修改 (modified) 和被删除 (deleted) 文件添加到暂存区，不包括新文件 (new)。
• git add -A (git add --all的缩写): 提交所有变化，是 add . 与 add -u 的合集。

git commit : 将暂存区内容提交到本地仓库中

• git commit -m [message] : 将暂存区内容提交到本地仓库中，message 是本次提交的描述信息
• git commit [file1] [file2] ... -m [message] : 将指定文件提交到本地仓库中
• git commit -a : -a 参数设置修改文件后不需要执行 git add 命令，直接来提交
• git commit -am [message] : -a 参数设置修改文件后不需要执行 git add 命令，直接来提交

git reset : 版本回退

git reset 的常用命令格式：git reset [--mixed | --soft | --hard | --merge | --keep] [HEAD]，默认是--mixed。

• HEAD 说明
  HEAD 是当前分支版本顶端的别名，指向我们在当前分支的最近一次提交。例如下面一共进行了A、B、C三次提交，则 HEAD 指向 C。

[commit A]--->[commit B]--->[commit C]                      

• 三种常用模式

1. --mixed : HEAD 指向指定 commit，暂存区回退到指定 commit 版本，工作区不变。

[commit A]--->[commit B]--->[commit C]---->[commit D]

小例子：看上述例子，共有 A、B、C、D 四个 commit，D 是最近一次提交，则 HEAD 指向 D。此时使用 git reset --mixed [commit B] 进行版本回退，则 HEAD 指向 B，暂存区回退到 B 版本，而 C、D 的 commit 内容会被回撤到工作区（即未被 git add 的状态）。

2. --soft : HEAD 指向指定 commit，指定 commit 及之后的 commit 的内容被回撤到暂存区，工作区保持不变。

小例子：还是看上述例子，共有 A、B、C、D 四个 commit，D 是最近一次提交，则 HEAD 指向 D。此时使用 git reset --soft [commit B] 进行版本回退，则 HEAD 指向 B，而 C、D 提交的内容则回撤到暂存区中（即已 git add 但未 git commit 状态）， C、D 的 commit 记录会被擦除，工作区中的内容不会发生改变。

3. --hard : 重置暂存区与工作区，回退到指定的 commit 版本。

小例子：还是看上述例子，共有 A、B、C、D 四个 commit，D 是最近一次提交，则 HEAD 指向 D。此时使用 git reset --hard [commit B] 进行版本回退，则 HEAD 指向 B，暂存区回退到 B 版本，工作区回退到 B 版本， C、D 的 commit 内容被丢弃。

另外还有 --keep 与 --merge 两种模式，但是不常用，此处不就不再详述。

4. 常见使用
   HEAD 与 HEAD~0 表示当前版本
   HEAD^ 与 HEAD~1 表示上一个版本
   HEAD^^ 与 HEAD~2 表示上上个版本
   HEAD^^^ 与 HEAD~3 表示上上上个版本
   以此类推...

git reset [模式] HEAD~1，表示回退到上个版本，或者我们也可以使用 git reset [模式] [commit id] 来回退到指定的 commit 版本。

3、Git分支管理

• git branch [branchname] : 以当前分支为模板，创建新分支
• git branch -d [branchname] : 删除指定分支
• git checkout [branchname] : 切换到指定分支我一
• git checkout -b [branchname] : 创建分支，切换到该分支
• git merge [branchname] : 将指定分支合并到当前分支
• git merge --no-ff [branchname] : 关闭 fast-forward 模式，将指定分支合并到当前分支，与 git merge [branchname] 的区别是 git merge --no-ff [branchname] 合并时会创建一个 merge 的 commit，保留原来的分支 commit 历史，一般推荐使用此种合并方式

master分支：[master-commit1]--->[master-commit2]
hotfix分支：[hotfix-commit3]--->[hotfix-commit4]

小例子：如上所示，当前我们在 master 分支，共进行了两次 commit；此外还有一个以 master 分支为模板创建的 hotfix 分支，共进行了两次 commit。

方式一： 我们使用 git merge hotfix 合并 hotfix 到 master 分支上，此时 hotfix 的 commit 记录会完全合并到 master 分支上，那么 master 分支上的 commit 记录为 [master-commit1]--->[master-commit2]--->[hotfix-commit3]--->[hotfix-commit4]，如下图左侧的图，master 的分支历史被扰乱。这时我们使用 git reset --hard HEAD^ 进行版本回退，则 master 会回退到 hotfix-commit3 版本。

方式二： 我们使用 git merge --no-ff hotfix 合并 hotfix 到 master 分支上，master 分支的 commit 历史会被保留，如下图右侧图。此时使用 git reset --hard HEAD^ 进行版本回退，则 master 会回退到 master-commit2

git merge 的不同

4、Git远程管理

• git clone [url] : 克隆项目
• git pull [远程主机名] [远程分支名]:[本地分支名] : 拉取指定远程分支与本地分支合并

小例子：

1. git pull origin master:test 将远程的 master 分支拉下来与本地的 test 分支合并
2. git pull origin master 如果是将远程分支与当前分支合并，则可以省略本地分支名，这里的意思是将远程的 master 分支与本地分支合并

• git push [远程主机名] [本地分支名]:[远程分支名] : 推送指定本地分支到远程并合并，如果远程分支不存在，则会创建远程分支

小例子：

1. git push origin test:master 将本地的 test 分支推送到远程 master 分支并合并；如果远程 master 分支不存在，则会在远程创建一个 master 分支
2. git push origin mater 如果本地分支名与远程分支名相同，则可以省略远程分支名

• git push origin --delete [远程分支名] : 删除指定的远程分支
• git tag -l : 显示已有标签
• git tag [tagname] : 创建标签
• git push origin [tagname] : 将本地标签推送到远程