文章目录
前言
本文模拟了真实企业标准流程和开发场景，以及辅助理解的前置知识。（拉到本文最后的补充知识章节） 力图搞明白真实企业Git管理情景！
真实企业开发场景
现在我们有两个分支：测试分支和生产分支
现在有一个需求，或者有一个bug。该需求有一个编号，假设就叫666。我是这个问题的主责任人。所以我可以这么做：基于测试分支拉出一个新分支，并将该分支命名为666号需求。
由于该问题是基于测试分支拉出来的，所以需要切换到测试分支（假设我的测试分支就叫master）(git checkout master)，然后在测试分支上执行命令：git branch 666Issue，就会拉取一个新的分支，该分支和测试环境分支长得一模一样。
执行完毕后结果：本地产生了一个新的分支：
然后执行git checkout 666Issue，切换到你新拉取的分支。然后你可以在这个新分支上写你自己的逻辑了！
写完逻辑之后，别忘了先fetch + merge一下远端测试分支和666Issue分支，保证远端测试分支和你本地的666Issue再次同步（这里不懂可以看下面的补充知识git merge和fetch）。 作好同步之后，执行git add，commit命令，将其推送到暂存区：
上图的领先情况只存在于本地！因为你还没有执行git push
详解 git push
到这一步都没问题，但是你不要轻易地git push。你先要了解git push的含义，才能进行git push。下面请看菜鸟教程：
假如你远程主机名只有一个 origin ， 那么你远程主机名都可以省略，直接写一个 git push命令，就可以将你代码push上去。
直接使用git push的场景是：远程主机名只有一个 origin 且 你所在的本地分支名和要推送到的远程分支名相同！
所以分析你现在所在的场景：你现在本地分支有一个 666Issue 分支，你远程没有 666Issue分支，远程主机名只有一个origin。此时我直接执行 git push，不出意外的话会报一个错误：
└─[$] git push
fatal: 当前分支 666Issue 没有对应的上游分支。
为推送当前分支并建立与远程上游的跟踪，使用
git push --set-upstream origin 666Issue
经过验证，非常好，果然报错。解决原因人家也给你写在下面了，你只需要执行该命令，就可以在远程上建立一个666Issue的分支（并且由于执行了push命令，本地的666Issue直接就提交到远程的666Issue分支了）：
你只有第一次这么做的时候需要这样，第二次这样的话，因为远程已经有了
而且你会发现，远程的666Issue分支，领先了被拉的master分支！
merge request将你的自定义分支merge到测试分支
打开你的gitee或者gitlib，下面以gitee为例，这上面叫做 Pull Request
然后你需要切换到开发经理的账号，等待你开发经理审批通过。
这样你的666Issue就被合并到了测试分支上。
回到你本地，执行一下git fetch命令，拉取远程，你会发现远程的测试分支果然合并了666Issue：
这样一来不会产生很多作废分支吗？并不是。标准开发中定期（一个月）清理掉已经解决问题的分支。
cherry-pick 或 merge 到生产分支
这是标准开发的最后一步。你测试环境更新了不少代码，就可以使用cherry-pick 或者merge命令，直接合并到生产分支，然后就可以上线了！
补充知识
如果上文说的你不懂，请看这里的补充知识点！
git fetch 的作用，以及和git pull的区别
git pull = git fetch + git merge
git pull还有一种合并模式，叫做变基合并（rebase），其实就相当于 git fetch + rebase
要理解fetch，要明白一个概念：远程仓库副本区域。它介于本地仓库和远程仓库之间，如下图所示：
(图来源于知乎波罗学)
git fetch 是将远程主机的最新内容拉到远程仓库副本区域，用户在检查了以后决定是否合并到工作本机分支中。如果决定合并到本地分支，可以使用git merge 就可以合并到工作本机分支！
如果有冲突，就解决冲突后merge到本地分支即可。
git fetch作用二： 用于从远程获取代码库。
假设你配置好了一个远程仓库，并且你想要提取更新的数据，你可以首先执行：
git fetch <远程主机名>命令来把远程某分支拉到远程仓库副本区域。
假如你直接写了git fetch，省略了远程主机名，那么就会将远程所有分支都拉下来。你就会看到远程所有分支了
所以你可以直接执行 git fetch 命令，获取远程所有其它分支。
fetch之前：
fetch之后 ：多了个分支
前置知识之git merge
git merge有非常多的参数和用法。这里我们只介绍最简单的用法。
直接写 git merge（省略参数），它会合并其上游分支。比如你现在所在的本地仓库是 A分支，远程仓库也有一个A分支，远程的A分支领先你本地的A分支1次commit。（你是怎么知道领先的消息的呢？肯定是通过git fetch得知）
你在执行git merge之前，肯定是先执行了git fetch的。然后你知道了远程的A领先了本地的A，你如果直接写git merge命令，那么就会将远程的A合并到本地的A。从此之后你的本地A分支就和远程A同步了。
这就是直接 git merge 省略参数的含义，在本地分支执行该命令后，会直接合并上游同名分支！
但是现在有这么2个场景：
- 一：开发分支（dev）上的代码达到上线的标准后，要合并到 master 分支
- 二：当master代码改动了，需要更新开发分支（dev）上的代码
应对1场景：fetch之后，需要切换(checkout)到master分支，执行 git merge dev命令，会将本地master分支与远程最新的dev分支进行合并。
应对2场景：首先执行fetch命令，切换到开发分支(dev)，之后执行git merge master命令，会将本地dev分支与远程最新的master分支进行合并。
其实1和2场景是一致的。只不过是git merge指定分支而已。