首先谈谈分支管理 ：
常用互联网开发中的分支管理有如下对应关系：
develop ------> 常用开发分支，会频繁变动
release ------> 测试环境分支， 即产品α版对应的分支，此分支须相对稳定
------> 预发布环境分支， 即产品β版对应的分支， β版与α版分支代码相同，区别在于β版使用线上数据库，α版使用测试环境
master ------> 正式环境分支，即产品正式版对应的分支。此分支需要特别稳定， 为正式生产级。
(以上可能各公司不尽相同，但大体是这样的对应关系)
谈完常用分支，谈一下分支管理的原则：
尽可能消除merge 与 revert log记录，尽可能使得git发布路线图单一。
例如：
这样的发布路线图就是特别成功的分支管理实践。
而下面：
这样的路线图关系特别混乱， 是非常不成功的。
接下来谈下develop分支开发管理实践：
开发某一特征或者修复某一bug时，
1先在develop分支（如本地没有，须从本地remote分支checkout出本地的develop分支）进行git pull命令，或者git fetch； git rebase命令；
2然后进行代码修改， 代码修改完成后git commit（如需与上次未push commit合并，请执行git commit --amend）,此操作将修改提交到本地仓库；
3执行git pull或git fetch ； git rebase；如有冲突解决冲突，然后git commit；
4git push将本地修改推到远程仓库；
如果集成了CI，此步操作会自动构建代码到α版环境；
此时如果测试通过需要构建到 预发布β版环境，则
1切换到release分支（远程release分支对应的本地分支），git pull;
2 git merge develop；(此操作建立在预发布最新commit与测试环境分支历史某一刻base相同的情况)；
如果预发布分支最新提交与develop分支没有任何关系，则考虑此最新提交是否要写到develop分支，
正常是需要的， 正常开发预发布环境和测试环境代码须保持一致；包括配置文件；配置文件可以写多个，
部署时从其中选择， 做到配置文件不影响代码仓库的整洁性。
如果这样， 可以保证release分支代码log中不包括merge的log，不包括merge的log可以使提交历史一目了然，所以代码管理的原则就是尽量减少merge以及revert等的log记录。
3 git pull；确保此过程没有别的用户在release分支有操作。
4 git push；
如果此过程出现了问题： 比如产生了冲突，或者遇到了产生merge log 以及revert log的情况，笔者经常遇到这样的情况 ：）. 需要做的是找到一个develop和release分支的base点：
如下图：
图中有release分支及develop分支， 最左侧为master分支打出的tag。这种情况一定不能merge，需要很好地处理。
1找到图中划线的基准点，确认基准点上的release分支上的所有提交在develop分支都存在，（如果不存在， 则须手动cherry-pick,一定要按提交顺序，以保证不产生merge 和revert 的log， 操作完成后记得执行push操作，因为release分支修改的代码， develop分支也是一定需要的）
2完成后， 在release分支上执行reset --hard <基准点commit的提交随机串> （PS:你没有看错， 就是--hard，放心， 因为你的代码在远程仓库上是有的， 所以大胆操作吧）
3 release 分支上执行 git push --force 此处一定需要--force，如果不这样， 本地分支在提交到remote端时会被rebase或者merge而恢复原有release分支的代码，或者产生merge操作的log， 这项操作就是为了使得远程分支的代码强制回退到基准点。
有人一定会问， 那这样不是丟掉了分支上的代码么， 对 ， 是的， 确实丢掉了， 但是别急， 因为develop 分支已经将release分支所有不一致的修改提交cherry-pick,所以代码还是有的， 放心操作吧。
4 release分支上执行git rebase develop ；因为release分支现在最新提交是和develop分支的某一历史提交， 所以直接执行git merge 操作不会产生任何问题（或者此时执行rebase操作也是可以的， 但是语义上来说git merge比较合适一点）。
5 git push 到remote(最好先pull一下以防release分支有别人的修改)
此时完成预发布环境的代码构建。
再谈一下master分支：
master分支是正式环境，线上环境的分支， 需要保持十分的稳定， 当出现bug时（包括紧急bug）， 不要直接在master上修改， 需要 在develop分支上改完，合到release验证通过后， 方能合到master。
所以master分支一般情况都是release分支的某一基准点， 所以在master和代码时，可以直接在master分支，进行git merge release操作。此时不会出现任何问题， 还可以保证代码仓库提交历史的干净整洁，只有功能和特征的描述；发布release notes时 ， 可以直接从commit messages提取。效果如下：
尽情享受干净整洁的代码仓库带来的好处吧！