Git创建Develop分支的命令：
git checkout -b develop masterDevelop本地分支推送到远程分支Develop
记得推到远端之前先拉取最新代码（会将远程仓库中这个分支上的更新和本地分支上的更新合并，如果两者之间有冲突，就需要手动解决冲突）
git branch --set-upstream-to=origin/develop develop
git pull
本地分支推送到远程分支
git push origin develop将Develop分支发布到Master分支的命令：
# 切换到Master分支
git checkout master
# 对Develop分支进行合并
git merge --no-ff develop使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。
前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：
* 功能（feature）分支
* 预发布（release）分支
* 修补bug（fixbug）分支这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。
接下来，一个个来看这三种"临时性分支"。
创建一个功能分支：
git checkout -b feature-x_a develop开发完成后，将功能分支合并到develop分支：
git checkout develop
git merge --no-ff feature-x_a 删除feature分支：
git branch -d feature-x_a 创建一个预发布分支：
git checkout -b release-1.2 develop确认没有问题后，合并到master分支：
git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点，做一个标签
git tag -a 1.2再合并到develop分支：
git checkout develop
git merge --no-ff release-1.2最后，删除预发布分支：
git branch -d release-1.2最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
创建一个修补bug分支：
git checkout -b fixbug-0.1 master修补结束后，合并到master分支：
git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1再合并到develop分支：
git checkout develop
git merge --no-ff fixbug-0.1最后，删除"修补bug分支"：
git branch -d fixbug-0.1
GitHub 开发流程的关键在于两点：
通过这样的开发流程，就相当于把自动化测试和代码审查作为一种强制性要求了，所有的修改必须要通过代码审查和自动化测试通过才能合并，从而保证有一个可以随时部署发布的稳定分支。
我们具体看看基于 Github flow 是如何开发的。
分支是 Git 中的核心概念，整个 GitHub 流程都是基于分支展开的，master 分支是要一直 保持稳定的，不能直接在 master 上开发。
无论你是要开发一个新功能还是修复一个 Bug，第一件事永远是从 master 创建一个分支 出来。
当创建好分支后，就可以基于分支开始工作了，这时候就可以按照如下原则，频繁的提交更新。
注意每次提交的时候，要加上说明性的信息，让其他人明确知道你这次提交的内 容是什么，如果开发过程中，发现错误了，还可以随时回滚之前的更改。
在开发完成后，创建一个 Pull Request（合并请求，简称 PR，Gitlab 中叫 Merge Request），创建 PR 时，通常要附上描述性的信息，关联上相应的 Ticket 连接，让其他 人知道你这个 PR 要完成什么任务。创建好 PR 后，其他人就可以直观的看到你所有的修 改。
当你的 PR 提交后，团队的其他人就可以对 PR 中的代码修改进行评论。比如说代码风格不 符合规范、缺少单元测试、或者很好没有问题。PR 的主要目的就是为了方便大家做代码审 查。
根据代码审查的结果，你可能要做一些修改，那么只要继续提交更新到这个分支就可以了， 提交更新后，PR 就会自动更新，其他人可以基于你的更新进一步的讨论和审查，直到通过 代码审查。
在合并前，还需要把分支的修改进行测试。理论上来说，需要将修改的内容部署到测试环境 测试，但这样效率太低了，所以通常的做法是借助持续集成工具，在每次提交代码后，就运 行自动化测试代码，自动化测试代码全部通过后，就可以认为质量是可靠的。
这也意味着你需要让项目中的自动化测试代码保持一定的测试覆盖率，否则质量还是难以保 障的。
当你的代码通过了代码审查和自动化测试，就可以将代码合并到 master 分支了。合并后， 之前的分支就可以删除，但你之前所有的提交记录在 master 都可以看到，所以完全不用担 心丢失历史版本记录。
以上就是 GitHub 开发流程的主要步骤，通过分支开发新功能或者修复 Bug，强制通过代 码审查和自动化测试才能合并 master，从而保证 master 的稳定。
要发布版本的话，从 master 上创建一个 Tag，例如 v1.0，然后将 Tag v1.0 上的内容部署 到生产环境。
如果线上发布的版本（例如 v1.0）发现 Bug，需要修复，那么基于之前的 Tag 创建一个分 支（例如 hotfix-v1.0-xxx）出去，在分支上修复，然后提交 PR，代码审查和自动化测试通 过后，从分支上创建一个新的 Tag （例如 v1.0.1），将新的 Tag 发布部署到生产环境，最 后再把修改合并回 master。
每次发布后，可以创建一个发布版本的分支，例如 release-v1.0，每次打补丁，都直接从 发布分支 release-v1.0 而不是 master 创建新的分支（例如 hotfix-release-v1.0-xxx）， 修复后提交 PR，代码审查和自动化测试通过后，合并回分支 release-v1.0，然后基于 release-v1.0 分支发布补丁。
最后将合并的 PR，借助 git 的 cherry-pick 命令再同步合并回 master
无论你基于哪一种开发流程，最好能做到这两点：
1. 有一个稳定的代码分支；
2. 在合并分支之前，对代码有审查，自动化测试要能通过。
这样你才能做到可以随时发布，质量稳定，高效协作。
其他：推荐一个简单好用的代码管理平台 gogs 非常轻量好用 比 gitlab 简洁很多