云服务器内容精选

  • Git工作流概述 什么是Git工作流?你可以理解为代码管理的分支策略,它不仅仅是版本管理范畴,更服务于项目流程管理和团队协同开发。所以,有必要制定适合自己研发场景的工作流。 下面介绍四种工作流的工作方式、优缺点,以及使用中的一些注意事项。 集中式工作流 功能分支工作流 Git flow工作流(推荐) Forking工作流 研发团队可以根据实际研发场景制定合理的工作流,能有效提高项目管理水平和团队协同开发能力, 并通过CodeArts Repo平台,高效、安全的管理代码资产,将更多的精力集中在业务开发上,实现持续集成、持续交付和快速迭代的目标。 父主题: Git工作流
  • 优点 使用一个用于发布准备的专门分支(release分支),使得一个团队可以在完善当前的发布版本的同时,可以在develop分支并行继续开发下个版本的功能。这也打造了可视化的发布阶段,团队成员都可以在仓库网状结构中可以看到发布状态。 使用紧急修复分支(hotfix分支)让团队可以处理紧急问题的同时而不打断其它工作或是等待下一个发布再合入hotfix修改。您可以把hotfix分支想成是一个直接在master分支上处理的临时发布。 大型项目人员协作频繁,流程较多,合理的多角色分支帮助研发有条不紊进行。 更符合devops理念。
  • 工作方式 master分支: 生产分支,最稳定的版本,一直是ready to deploy状态。不接受开发人员直接commit,只接受从其他分支merge操作。在很多企业中,这个分支被默认开启分支保护,只有维护者可以操作。 hotfix分支: 从master分支拉取的临时修复分支,用于解决一线紧急bug。bug解决后需要合入master分支并打上新的版本号,这个修改也需要同时合入develop分支。 develop分支: 从master分支拉取的开发分支,用于功能集成。包含所有要发布到下一个Release的代码用于开发集成、系统测试。 release分支: 临近既定的发布日,就从develop分支上拉取一个release分支,任何不在当前分支中的新功能都推到下个发布中。release分支用于发布,所以从当前时间点之后新的功能不能再加到这个分支上,这个分支只做Bug修复、文档生成和其它面向发布的任务。当对外发布的工作都完成了,release分支合并到master分支并分配一个版本号打好Tag;另外,这些从release分支新做的修改要反向合并回develop分支。 feature分支: 开发者使用的特性分支,父分支是develop分支,当新功能完成时,合入develop分支。新功能提交从不直接与master分支交互。