gitflow工作流

  • 开发者

    • 创建自己的功能分支
    • 在自己的功能分支上进行开发
    • 提交合并请求
    • 在维护分支和测试分支中对代码进行修改
  • 项目经理
    • 创建develop分支
    • 审批合并请求
    • 合并测试分支到主分支

gitflow演示

git checkout -b develop origin/develop  # 创建并切换到本地develop分支, 设置其追踪的远程分支为origin/develop
git checkout -b f_detail # 创建并切换到本地分支f_detail

git branch -d f_detail   # 删除本地分支
git push --delete origin/f_detail  # 删除远程分支

# 解决合并冲突(提交合并请求时, 出现了叹号)
git checkout develop
git pull develop
git checkout f_order
git merge develop
git add .
git commmit
git push
重新发起合并请求

# 项目经理  将指定的版本合并到分支
git cherry-pick 版本号

原文地址:https://www.cnblogs.com/oklizz/p/11405815.html

时间: 2024-07-31 02:51:57

gitflow工作流的相关文章

Git基本命令和GitFlow工作流

本篇博客讲解了git的一些基本的团队协作命令,和GitFlow工作流指南 git 团队协作的一些命令 1.开分支 git branch 新分支名 例如,在master分支下,新开一个开发分支: git branch dev 2.切换到新分支 git checkout 分支名 例如,在master分支下,切换到新开的dev: git checkout dev 3.开分支和切换分支合并到一个命令 git checkout -b 新分支名 例如,新开一个开发分支,并立即切换到该分支: git chec

gitflow工作流简介

gitflow工作流是一种依赖于Git版本管理工具,按特定规范对项目开发.测试.上线流程进行管理的工作方式.它是一种为实现规范化管理的约定,它明确了各个分支的意义,使整个团队的分工协作更加和谐明晰. 一.gitflow工作流约定使用的分支简介 [master]项目的核心分支,也是最终对外发布的分支,唯一且稳定.仅提供可读,不可在该分支上直接修改代码. [develop]项目的开发主干分支,唯一.仅提供可读,不可在该分支上直接修改代码.新功能的开发需从该分支拉取新的分支展开.develop分支应该

GitFlow 工作流

1.概述 GitFlow 工作流定义了一个围绕项目发布的严格分支模型.虽然比功能分支工作流复杂几分,但提供了用于一个健壮的用于管理大型项目的框架. GitFlow 工作流没有用超出功能分支工作流的概念和命令,而是为不同的分支分配一个很明确的角色,并定义分支之间如何和什么时候进行交互.除了使用功能分支,在做准备.维护和记录发布也使用各自的分支.当然你可以用上功能分支工作流所有的好处:Pull Requests.隔离实验性开发和更高效的协作. 2.工作方式 GitFlow 工作流仍然用中央仓库作为所

Git之GitFlow工作流

一. GitFlow 介绍 1.1 什么是 GitFlow GitFlow 是一种 Git 工作流,它是团队成员遵守的一种代码管理方案 . 1.2 GitFlow 常用分支说明 分支名称 分支说明 Production 生产分支,即 Master分支.只能从其他分支合并,不能直接修改 Release 发布分支,基于 Develop 分支创建,待发布完成后合并到 Develop 和 Production 分支去 Develop 主开发分支,包含所有要发布到下一个 Release 的代码,该分支主要

GitFlow工作流常用操作流程

1. 主要分支介绍 1.1 master分支 主分支,产品的功能全部实现后,最终在master分支对外发布. 1.2 develop分支 开发分支,基于master分支克隆,产品的编码工作在此分支进行. 1.3 release分支 测试分支,基于delevop分支克隆,产品编码工作完成后,发布到本分支测试,测试过程中发现的小bug直接在本分支进行修复,修复完成后合并到develop分支.本分支属于临时分支,目的实现后可删除分支. 1.4 bugfix分支 Bug修复分支,基于master分支或发

深入理解学习Git工作流

一.译序 工作流其实不是一个初级主题,背后的本质问题其实是有效的项目流程管理和高效的开发协同约定,不仅是Git或SVN等VCS或SCM工具的使用. 这篇指南以大家在SVN中已经广为熟悉使用的集中式工作流作为起点,循序渐进地演进到其它高效的分布式工作流,还介绍了如何配合使用便利的Pull Request功能,体系地讲解了各种工作流的应用. 行文中实践原则和操作示例并重,对于Git的资深玩家可以梳理思考提升,而新接触的同学,也可以跟着step-by-step操作来操练学习并在实际工作中上手使用. 关

深入学习 Git 工作流

原文  https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md 个人在学习git工作流的过程中,从原有的 SVN 模式很难完全理解git的协作模式,直到有一天我看到了下面的文章,好多遗留在心中的困惑迎刃而解: 我们以使用SVN的工作流来使用git有什么不妥? git 方便的branch在哪里,团队多人如何协作?冲突了怎么办?如何进行发布控制? 经典的master-发布.develop-主开发.hotfix-不过修

Git - Pull Request工作流

Pull Requests是Bitbucket上方便开发者之间协作的功能.提供了一个用户友好的Web界面,在集成提交的变更到正式项目前可以对变更进行讨论. 开发者向团队成员通知功能开发已经完成,Pull Requests是最简单的用法.开发者完成功能开发后,通过Bitbucket账号发起一个Pull Request.这样让涉及这个功能的所有人知道,要去做Code Review和合并到master分支. 但是,Pull Request远不止一个简单的通知,而是为讨论提交的功能的一个专门论坛.如果变

四种常见 Git 工作流比较

轉載:http://toutiao.io/contribute 多种多样的工作流使得在项目中实施Git时变得难以选择.这份教程提供了一个出发点,调查企业团队最常见的Git工作流. 阅读的时候,请记住工作流应该是一种规范而不是金科玉律.我们希望向你展示所有工作流,让你融会贯通,因地制宜. 这份教程讨论了下面四种工作流: 中心化的工作流 基于功能分支的工作流 Gitflow工作流 Fork工作流 中心化的工作流 过渡到分布式分版本控制系统看起来是个令人恐惧的任务,但你不必为了利用Git的优点而改变你