三人小团队git分支协作试水

场景:

正在开发某一个新功能

或修复某个bug,未完全完成时

暂时不能提交到master

此时

测试需要更新一个测试版本

或者其他...

  然而  master并不能正常跑通所有流程

思路:

  1.保证有一份代码是无论何时都是可正常跑通所有流程的完全体代码,要求新增的功能可能已经部分添加进去也可能没有,反正测试人员就是要重新再安装一个最新版本 : (

  2.正在开发的功能在未完成之前不能交给测试人员来运行测试,但是也不能为了装新版本久把刚写不多的代码注释活着删掉(我以前就这么干过,猪都笑我)

  3.新增的需求可以随时加入到之前版本的代码中去(千万不要用了git还用拷贝文件的方式来做版本管理,呵呵)

  4.很吊的样子

方案:

先创建开发分支

$ git branch dev

现存分支:

       两条  分支  

          

          

       ------------- 

     |                                          |

      |                                          |

     master                       dev  

开发新功能或者修改bug时,切换到dev分支

1.先查看当前分支

$ git branch

2.切换到开发分支

$  git checkout dev

3.编码过程中,每次完成一部分  就把代码合并到master分支

$  git commit -a -m  "<commit message>"   (可用Xcode commit 替代此步骤)

$  git checkout master

$  git merge dev

4.获取最新的master版本

$  git tf pull

5.本地处理master合并产生冲突

6.并将合并后的master 推送到TFS

$  git tf checkin

    (或者git远程库)略

时间: 2024-10-11 01:19:33

三人小团队git分支协作试水的相关文章

一个 Git 分支协作模式的进化故事

从不用版本管理到使用 Git 分支管理的故事,也就是从这个时候开始的... 某公司只有一个程序员,一开始并没有版本管理的概念.项目开发只有一个人在参与,所以也没用版本管理工具. 后来,老板又招了两个程序员,老板说:“研发管理要规范!”,经过一番调研,选用了 Git,三个人开始使用 Git 进行开发上的协作. 一开始,三个人都是通过一个仓库,在 master 分支上进行协作.每天上班第一件事就是先把最新的代码从服务器上拉到本地的 master 分支,下班前再把代码给推到服务器上的 master 分

自学it18大数据笔记-第三阶段Spark-day14;Spark-day15(开始试水找工作了)——会持续更新……

写在最前:转行大数据领域,没报班,自学试试,能坚持下来以后就好好做这行,不能就--!准备从现有这套it18掌的视屏残本开始--自学是痛苦的,发博客和大家分享下学习成果--也是监督自己,督促自己坚持学下去. (教学视屏是it18掌做活动送的,视屏不是很全,课堂笔记和源码等课堂相关资料也未放出,但徐培成老师课讲的真心很好,感兴趣的不妨听听,特此感谢it18掌--帮他们打打广告) 笔记为自学时记录,如有错误,欢迎指正,不胜感激!现已广州转移至上海,开始试水找工作了,欢迎小伙伴们加qq或微博沟通交流(Q

Meth | 小团队git开发模式

这种模式的开发流程如下: 1.由其中一个开发者这服务器上建立一个数据库. 所有开发者都可以向数据库提交和下载东西,这里必须规定一定的时间间隔(一周或者一天)必须提交一次,不然以后解决冲突时是个大问题. 如果每个人的开发耦合度很高,我们可在服务器上建立分支,然后每人每次提交到自己的分支上,过一段时间之后(不能太久)有一个人去合并分支.然后所有 人更新自己的数据库的master分支,使之跟服务器上的master分支同步.2.这样服务器会有非常多的版本信息,集合了每个人的版本信息.过了一段时间之后,例

Git 在小团队中的管理流程(转)

目标读者:了解 Git 的基本概念,能够使用 Git 进行基本的本地和远程操作. 有关 Git 的基础知识可以参见 知乎回答-怎样使用 GitHub?,天猪(刘勇)给出了一些很好的学习资料. 本文介绍了小团队中 Git 管理的基本使用流程.小团队的代码管理可以采用这样一种方式:项目存在一个中心远程仓库,作为团队成员进行代码交流的主要场所.同时可以存在一些成员远程仓库,用于局限在团队中部分成员间的代码交流.并将成员分成以下几类不同的角色:负责人.普通组员.预发布责任人 和 版本修复责任人.下面的章

团队项目的Git分支管理规范

原文地址: http://blog.jboost.cn/2019/06/17/git-branch.html 许多公司的开发团队都采用Git来做代码版本控制.如何有效地协同开发人员之间,以及开发.测试.上线各环节的工作,可能都有各自的流程与规范.本文分享的是作者一直沿用的团队项目Git分支管理规范,希望给有缘阅读的人以参考,如果有更好的实践,也欢迎探讨.交流. 分支管理 创建项目时(一般是服务型项目,工具型或辅助型项目可以简单一些),会针对不同环境创建三个常设分支: develop:开发环境的稳

Git 教程(三):仓库与分支

远程仓库 到目前为止,我们已经掌握了如何在Git仓库里对一个文件进行时光穿梭,你再也不用担心文件备份或者丢失的问题了. 可是有用过集中式版本控制系统SVN的童鞋会站出来说,这些功能在SVN里早就有了,没看出Git有什么特别的地方. 没错,如果只是在一个仓库里管理文件历史,Git和SVN真没啥区别.为了保证你现在所学的Git物超所值,将来绝对不会后悔,同时为了打击已经不幸学了SVN的童鞋,本章开始介绍Git的杀手级功能之一(注意是之一,也就是后面还有之二,之三--):远程仓库. Git是分布式版本

《小团队项目管理》第三问 --- 如何看待客户的需求变更?

作为一名码农,在项目开发过程中经常会涉及到项目的需求变更,变更的理由也是多种多样,总结而来分为外部和内部,从外部讲,例如:为了顺应某行业新的工作操作规范,甲方要求现有项目在工作流程环节上进行局部功能的变更:从内部讲,通过对市场环境的不间断调研和数据分析,公司产品在同类产品竞争中处于不利地位,市场份额日渐缩小,那么我们的产品设计人员会积极行动起来对产品的整个定位和新业务展开新的思考以寻求更加稳健的创新突破口,这就会对项目产生一定的需求变更. 此图是从CSDN社区截取下的,我相信很多看到这个问题的筒

版本控制git(三)-git分支

通过本系列的上两篇文章(查看系列文章:http://www.cnblogs.com/jerehedu/p/4607599.html#bbkz),我们已经知道了如何使用Git完成对文件的版本控制.本次我们继续学习如何通过Git进行分支管理. 首先,我们要弄明白什么是分支.通过git log 命令我们可以查看版本库的提交日志,如图: 那么这些commit之间存在什么关系呢?实际上每次commit的时候,提交对象都会保存一个指向上次一commit版本的指针,经过多次提交之后,git通过这个指针将多个提

多人合作使用git,推送代码、和并分支

多人合作使用git,推送代码.和并分支 原文地址:https://www.cnblogs.com/zxlb/p/12318271.html