手机网站图片宽度,有哪些网站可以兼职做笔译,抖音代运营包含哪些服务,企业咨询图片目录 1.分支管理策略 2.我用的分支管理策略 3.一些常见问题 1.分支管理策略 分支管理策略就是一些经过实践后总结出来的可靠的分支管理的办法#xff0c;让分支之间能科学合理、高效的进行协作#xff0c;帮助我们在整个开发流程中合理的管理好代码版本。 目前有两套Git…目录 1.分支管理策略 2.我用的分支管理策略 3.一些常见问题 1.分支管理策略 分支管理策略就是一些经过实践后总结出来的可靠的分支管理的办法让分支之间能科学合理、高效的进行协作帮助我们在整个开发流程中合理的管理好代码版本。 目前有两套Git分支管理策略GitHub Flow和GitFlow它们各自定义了一套规范帮助开发者更好地组织和管理源代码的版本控制流程。 GitHub Flow 简介 GitHub Flow 是由GitHub团队推广的一种简单、灵活且快速的工作流程特别适合小型团队和持续交付环境。 核心概念 所有开发都是基于main分支原称master现在推荐使用main。 新的功能开发通过创建短期的特性分支feature branches。 特性分支完成后通过Pull Request (PR) 提交到main分支。 PR期间进行讨论、审查和自动化测试只有当所有工作满足要求时才将其合并至main。 优点 GitHub Flow的优势是快速迭代频繁部署强调每个特性分支都应具备随时可部署的状态。 GitFlow 简介 GitFlow 是一种更为严谨和复杂的分支模型适用于大型项目和需要严格版本控制的企业级开发环境。 核心概念 分支分为两大类持久分支和临时分支。 持久分支包括main稳定版、develop开发版。 临时分支包括feature特性分支、release发布分支、hotfix热修复分支。 develop分支作为日常开发集成的分支每次新增功能或修复都在独立的feature分支上完成完成后合并回develop。 当产品即将发布时创建一个release分支进行测试和最后的调整确认无误后合并到main和develop并打上版本标签。 如果生产环境中发现了紧急问题那么在main基础上创建hotfix分支进行修复修复完毕后同样合并回main和develop。 优势 结构清晰易于跟踪每个阶段的代码状态有利于多人协同和大型项目管理尤其对于那些有明确版本周期和稳定版需求的项目。 总结来说GitHub Flow 更注重敏捷开发和快速迭代简化了分支结构而 GitFlow 则提供了详细的分支管理方案更适合需要精细化版本管理和长周期开发的场景。目前市面上各团队常用的管理策略基本上都是基于GitHub Flow策略的。 2.我用的分支管理策略 目前作者所在的团队采用的分支管理策略就是基于GitHub Flow策略的。 我们有以下几个分支 master稳定主分支 pre-release稳定测试分支 develop开发分支 feature单人新特性分支 release发布分支 patch维护分支 当我们开发新功能的时候会先分一下任务然后各自从develop分支上拉一个属于自己的feature分支这个feature一般会命名为下个版本的版本号-feature-自己名字的缩写 任务有轻重缓急和难易之分一个大版本的所有新需求很难在统一的一个时间点上完成所以一般都是分批次提测的最后合并在一起发版。提测的时候各自将自己要提测的内容从自己的feature上合并到develop分支上再从develop分支合并到pre-release上。将pre-release部署到测试环境中用于测试。之所以这样做是在实践中发现很多时候develop并不是稳定的大家都在往上面合并代码直接将develop用于部署测试往往无法保证测试环境的稳定会造成阻塞。所以有一个pre-release用来保证测试环境的稳定。测试期间的bug修复也是先修自己的feature然后合并到develop然后合并到pre-release。 要注意上面的合并一般指的都是cherry pick一条一条的合并分支级别的merge是很容易将pre-release和develop合乱的。 所有新特性都测试完成后将develop合并到release上然后基于release打tag发版。 发版后有可能还会发现一些bug一般会基于发版的tag拉一个patch分支来进行快速修复。这时候修复的bug会先在patch上修复修复完毕后合并到develop分支上。最后这个patch分支在维护一段时间后会被丢弃。 3.一些常见问题 1.如何打tag 在IDEA种可以通过图形化的界面来打tag 也可以通过命令来打tag git tag -a tag-name -m tag-message 打完tag之后push到远端仓库即可。 2.如何切到某个tag 打完tag之后有些时候我们要用到打tag的代码版本可以通过命令跳过去 git checkout -b new-branch-name tag-name 3.如何基于tag拉分支 打完tag代码就算是封板了但是发版后仍然会有一些小问题会持续暴露出来需要我们持续修复于是我们需要基于tag拉出一个hotfix分支来在这个分支上进行发版后的bug修复可以通过命令来从某个tag拉出一个分支 git checkout -b new-branch-name tag-name 3.如何合并 在hotfix上修复的bug在当前的开发分支上当然也是存在的所以我们要将hotfix上的bug修复持续的合并到开发分支上这时候尽量不要用分支级别的合并命令merge来操作尽量将bugfix一条一条的合并到开发分支上。 在IDEA上可以直接通过图形化界面将某个分支上的修改单条的合并到当前分支。操作很简单首先保证自己当前在接收合并的分支上然后在git log中找到要合并过来的提交cherry pick过来即可 4.如何比对分支之间的区别 从hotfix合并到develop分支这种两个分支之间一条一条的合并难免会合并漏最好的方式当然是要比对出两个分支之间的差异在IDEA中很好比对差异