R3emix

git flow, Git 分支管理, github flow, gitlab flow git flow main: 稳定的生产代码，只有发布版本才合并到这里, 长期分支，始终存在。 develop：日常开发的主分支，所有新功能和 bug 修复先合并到 develop, 长期分支，始终存在。用于整合开发中的代码 feature/xxx：新功能开发的临时分支，开发完成后合并到 develop, 合并之后删掉, 短期分支， 不是长期保持。开发新特性时创建,合并后删除 release/xxx：发布准备分支，从 develop 分出，准备发布, 短期分支， 不是长期保持。 hotfix/xxx：生产环境紧急修复，从 main 分出，修复后合并回 main 和 develop, 短期分支， 不是长期保持。 Git flow 是一个Git分支管理模型，由 Vincent Driessen 于2010年发布在其个人网站的一篇博文中《A successful Git branching model》，该模型适用于多版本管理的项目，能够有效的促进团队成员之间的协作，提升代码的清晰度。 https://nvie.com/posts/a-successful-git-branching-model/ https://www.cnblogs.com/youbins/p/17632165.html Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。 更大问题在于，这个模式是基于”版本发布”的，目标是一段时间以后产出一个新版本。但是，很多网站项目是”持续发布”，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。 github flow 只有主分支（通常是 main 或 master）和临时 feature 分支。 在 GitHub Flow 中并不推荐或保留 develop 分支。 feature/bugfix 分支：开发新功能或修复 bug 时，从 main 分出，开发完成后提 Pull Request（PR），通过代码审查后合并到 main。开发完成后通过 Pull Request 合并到 main，feature 分支随即删除。 GitHub Flow 本身不适合多版本并行维护 https://docs.github.com/en/get-started/using-github/github-flow ...