## 开发流程 master：线上稳定版本（所有功能都是稳定的） dev：新功能测试版本（每个功能都是基本完整的，可用的，但可能不稳定，属于测试阶段） xiak-monitor-pay：功能开发分支（开发中） ... ---- ### 线上紧急问题修复 直接从master 拉一个 fix-bug 分支出来修复，测试完毕后，然后合并到master以解决紧急问题 然后不要忘了，dev 和 功能开发分支 要拉 master 的更新 ---- ### git开发流程/规则 **master：主分支，线上生产环境代码** **dev：开发测试分支，测试环境代码，用于内部测试** 1. master和dev上从不直接修改代码，只接受合并 2. 开发新功能和迭代永远只在master拉分支出来的功能分支上进行 3. 开发过程中，经常从master往自己的功能分支合并，越频繁越好（重复三遍） 4. 功能开发完毕（最新的master往上合过并通过自测才算是开发完毕），先合到dev上进行测试 5. 测试(内侧)没问题就可以往master上合并上线 6. 如果一个功能最初是从某个功能分支中出来的，那么只要涉及该功能的更新，就需要一直维护该分支，没有特殊情况不要抛弃它而去建立新的迭代分支，确保不要出现一个功能分散在多个分支中 7. 建立功能分支时功能要确定，不能模棱两可，一个功能只能在一个分支中，确保该功能的整个生命周期都由该分支来维护和迭代。 8. 功能分支只有测试通过，需要直接上线时才需要往master上合并 9. 经常从master往自己所开发的功能分支上合并是好习惯 10. dev只能接受合并，永远不能往其他任何分支合并，切记！ 11. git的合并操作是：往当前所在的分支合，一定不要看错了当前所在分支（命令行中可能没实时显示，按下回车或查看当前所在分支） 12. 功能分支的粒度要尽量小，不要把很多功能都放在一个功能分支中，尽量一个小功能一个功能分支 13. 处于开发的功能分支之间不能有任何肢体接触 14. 处于开发的功能分支是不完备的，经常有coding...这样临时保存代码的提交，而dev和master上，决不允许出现这样的提交（HEAD） 15. 有时候需要单独测试某个功能分支，dev.abc.com环境切换为需测试的分支即可 16. 每次开始写代码前，不要忘记git pull拉代码，并且开发过程中需要经常拉代码，越频繁越好，因为即使某一个功能分支也往往是由多人同时开发的。 17. 功能开发完毕后合并到master分支上线时别忘记了检查开发时的一些为开发环境所作的特定配置修改，如一些硬编码的配置参数，要仔细检查，如预定功能的预定限额(硬编码)，开发时往往为了方便会调整这些值，但是正式上线时一定要修改为正式环境的配置再上线。否则如果把开发/测试环境的配置带到线上了就会造成严重的后果。 严格遵守以上规则，如果你发现你想做的操作不包含在以上规则中，则一定不要做！ ---- ### 其他 当然如果时间过去很久，都差不多忘记当初的分支了，也可以抛弃它再新建分支 ---- **速记：** master：可以把我合到任何地方，但别轻易合并到我身上。 dev：要测试的往我这儿合并，但不要让我合并到你身上，否则你就完了。 上线：上线时检查所有开发环境的配置(硬编码参数等)，确保线上除了逻辑代码正常外所有软硬配置也要正确。 各功能分支间：尽量不要有交流，实在想交流的话，彼此得要做好充分的准备，沟通协商好（这意味着两个功能有不可避免的耦合）；如果上线了，要交流通过master。 ---- last update：2019-8-8 14:22:53