[Git工作流]主管很欣赏你，决定让你独自负责一个活

本节课会学习使用Git管理代码的常见工作流。

经过前面课程，你已经可以很快的上手进行编码开发了。主管觉得你很优秀，十分的欣赏你，决定让你独自负责一个活。那么这个时候你就需要知道Git工作流了。

Git的工作流有很多，这里只介绍一种常见的工作流。因为有些项目极其复杂，比如linux之类的仓库，考虑的情况会很多，他们的Git工作流就会比较复杂，不过都是基于本文介绍的工作流的变种。

接下来，我们按照工作流程来讲解。

拉取代码

首先通过命令拉取仓库分支，并创建你的开发分支dev2

# 克隆新仓库代码
git clone xxxx.git
# 如果已经克隆过，就创建并切换到一个新分支dev2
git checkout -b dev2

因为这个仓库的代码，你的同事小明也在上面开发新功能，小明的分支叫dev1。那么你本地的仓库分支就会长这个样子：

你在dev2分支上提交了很多代码，小明也在dev1上提交了很多代码。这个时候你更新了本地代码后，你本地的仓库就长这样：

开发与合并代码

这个时候，如果你要先发布，是可以直接merge master去发布的。因为远程的master和你本地的master是一样的。调用命令merge

# 切换分支到master
git checkout master
# 合并dev2
git merge dev2
# 推送代码
git push origin master

当然上面这种操作，会出现问题。比如小明先发布了，那么关系会变成下面这个图：

这个时候你进行git push origin master就会报错，因为本地master和远程master都包含了不同的提交。

我们要先把远程master更新到本地master，再进行merge dev2，再提交。这样，就不会出现master和远程master的冲突。

所以我们需要用以下这个流程来合并提交代码。

# 在切换分支进行合并
git checkout master
# 拉取远程改定，并合并origin/master到本地master。
# 也可以用git fetch  + git merge
git pull

这样一波操作下来，关系图就是这样的。

现在，本地master和远程master是一样的了， 我们就可以进行merge操作了。必须先在dev2合并master，再合并会master(这里的合并一般会走Pull Request，方便Code Review)，这样保证合并的代码修改不在master直接改动。

# 切换到dev2。
git checkout dev2
# 合并
git merge master
# 解决冲突
# 重新提交
git commit -am 'xxx'
# 推送代码到远程
git push

Pull Request（PR）

最后，你需要把dev2的代码合并会master。一般我们会使用Pull Request功能，因为在Pull Request里面，可以进行Code Review（代码评审）。

在网站上创建一个Pull Request。以gitee为例，在仓库的Pull Request中，创建一个新PR，源分支就是dev2，目标分支就是master。

代码评审通过后，dev2的代码就会合并到master。关系变成下面这样

发布

最后，如果我们已经完成开发，需要打标签进行发布，那么就可以用以下命令。

git tag v1.1
git push

结果就是：

总结

上面这个是最简单最参见的工作流。流程中主要约定了多个分支迭代开发中，分支发布先后顺序不同，导致的合并问题。 实际开发中，分支类型会有很多，比如一个大项目，会先拉出来一个develop分支，然后再从develop中拉出多个feature分支，我们会在feature分支上做开发。完成功能开发后会合并回develop分支。准备发布前，又会单独拉出一个release分支专门用于发布。如下图所示： 但是万变不离其宗，核心都是要弄明白主干和各个开发分支的关系，以及你的开发分支该和谁去合并。（具体的分支约定，每个公司都不同）