[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分支专门用于发布。如下图所示： 可是万变不离其宗，核心都是要弄明白骨干和各个开发分支的联系，以及你的开发分支该和谁去兼并。（具体的分支约好，每个公司都不同）

开启成长之旅！这是我参加「日新计划 2 月更文应战」的第 11 天，点击查看活动概况