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

 

目标读者:了解 Git 的基本概念,能够使用 Git 进行基本的本地和远程操作。

有关 Git 的基础知识可以参见 知乎回答-怎样使用 GitHub?,天猪(刘勇)给出了一些很好的学习资料。

本文介绍了小团队中 Git 管理的基本使用流程。
小团队的代码管理可以采用这样一种方式:项目存在一个中心远程仓库,作为团队成员进行代码交流的主要场所。同时可以存在一些成员远程仓库,用于局限在团队中部分成员间的代码交流。并将成员分成以下几类不同的角色:负责人、普通组员、预发布责任人 和 版本修复责任人。下面的章节具体介绍了各类角色的 Git 使用流程。

基本须知
需要多个人共同完成的分支可以建立远程分支,单个人完成的分支只建立本地分支即可。

一、负责人

负责人的职责:管理远程仓库。
负责人的工作均可直接在远程仓库完成。

1.创建项目

  • 创建公有项目
  • 添加README.md
  • 添加证书
  • 添加忽略文件
  • 创建 dev 分支

2.其他

  • 更新 README.md 文件

二、组员

工作流程

  • 克隆项目
  • 签出并创建 dev 分支,使其跟踪远程的 origin/dev 分支。
  • 在dev分支基础上创建自己的分支 member* 。

  • 在自己的分支上添加文件
  • 在自己的分支上修改文件
  • 合并到dev分支
  • 推送dev分支到origin/dev分支

// 更新 .gitignore 文件

  • 从 dev 新建一个分支 ignore (如果预测变更频繁就建立一个远程分支,现在一般都有模板,偶尔有个没有忽略的直接在dev分支上改就可以了)
  • 更新忽略文件
  • 尽快合并到\推送到 origin/dev 分支 (避免两个组员同时更改该文件造成冲突。)

1.创建本地仓库

$ cd [项目路径]
$ git clone https://coding.net/tangyikejun/GitTest2.git
$ git checkout -u -b dev origin/dev
$ git checkout -b [MEMBER_NAME];

2.更新本地仓库

$ git add .
$ git commit -m”your comments”
       // …                                               // 多次提交后完成了一项新的功能,自己的分支下能正常运行
$ git checkout dev
$ git merge --no-ff [MEMBER_NAME]                       // [MEMBER_NAME] 是自己的分支名称
$ git push

3.更新 .gitignore 文件

$ git checkout dev
        //…                                               // 更新忽略文件
$ git add .
$ git commit -m“更新.gitignore文件”
$ git push

4.常用查询命令

$ git branch                                            // 查看自己所在分支 以及自己所拥有的分支
$ git log --pretty=“%h - %cn(%ci): %s” --graph          // 查看自己的提交记录
$ git reflog                                            // 查看自己的操作历史
$ git status                                            // 查看本地仓库当前的文件状态
$ git blame [FILE_PATH] 			                    // 查看文件的每一部分最后由谁改动

5.意外情况处理

意外:推送代码到远程 dev 分支时发生冲突。
解决方案:先把 远程仓库的 origin/dev 分支拉取下来,解决冲突文件后再推送。平时的时候尽量避免不同组员更改同一个文件。

$ git push 

       // …                                               // 遇到错误

$ git pull

       // …                                               // 解决冲突

$ git add .
$ git commit -m”solve conflict:由于XX原因出错,修改XX文件解决问题”
$ git push


意外:不小心把自己的工作成果push到了master分支。
解决方案:先对master进行回退,再使用git push -f将错误的提交删除。


三、预发布责任人 & 版本修复责任人

1.预发布责任人

当需要发布新的版本时,预发布责任人:

  • 基于最新的 dev 分支创建一个 release-版本号 分支
  • 进行修缮工作
  • 合并到 dev 分支
  • 合并到 master 分支
  • 打标签
  • 删除 release-版本号 分支
$ git checkout dev
$ git pull
$ git checkout -b release-1.2
        //…                                               // 进行修缮工作
$ git checkout dev
$ git merge --no-ff release-1.2
$ git checkout master
$ git merge --no-ff release-1.2                         // 在评论中写入相比上个版本新增的功能,修复的bug等详细内容
$ git tag v1.2
$ git branch -d release-1.2

使用 git show [TAG_NAME]可以查看标签对应的提交信息。

2.版本修复责任人

当新发布的版本发现 bug 时,版本修复责任人:

  • 基于最新的 master 分支创建一个 hotfix-版本号 分支
  • 进行debug工作
  • 合并到 master 分支
  • 打标签
  • 合并到 dev 分支
  • 删除 hotfix-版本号 分支
$ git checkout master
$ git pull
$ git checkout -b hotfix-1.2.1
        //…                                               // 进行修缮工作
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag v1.2.1
$ git checkout dev
$ git merge --no-ff hotfix-1.2.1                        // 在评论中写入修复的bug等详细内容
$ git branch -d hotfix-1.2.1

3.意外情况处理

意外:某组员完成自己的任务后合并到 dev 分支,推送时发现 release 分支的修缮工作更改了自己原来的文件,产生了冲突。
解决方案:把 origin/dev 分支拉取下来,将冲突解决后再次提交。(注意这里解决冲突后 master 分支上的文件与该组员的工作成果依旧是有冲突的。除非该组员解决冲突时不更改 relese 时的修缮代码,而仅仅更改自己的代码来解决问题。因此,一旦有冲突产生,最好双方进行合理交流达成一致意见。减少冲突。)


四、成员远程仓库

当某个团队成员希望其他成员协助完成他的编程任务时,该成员可以为自己的本地仓库创建一个远程仓库作为成员远程仓库,方便其他成员协助。建立成员远程仓库可以避免中心远程仓库的代码交流繁杂混乱。
成员远程仓库在在操作上是中心远程仓库的简化版。仅在细微处有所不同。

1.求助者

  • 创建成员远程仓库
  • 添加成员远程仓库
  • 推送自己的分支到成员远程仓库的 master 分支
  • 拉取成员远程仓库的 master 分支到自己的分支
$ git remote add [ALIAS_NAME] [GIT_ADRESS]
$ git push [ALIAS_NAME]  [BRANCH_NAME]:[BRANCH_NAME_REMOTE] 

$ git pull

举例:

$ git remote add binRepo https://coding.net/chenbin/GitTest2.git
$ git push binbin  binRepo:master                               //由于是第一次推送,该操作已经使得分支binbin 跟踪了远程分支 binRepo/mastr

当某个分支 a 跟踪了远程分支 b,即 b 成为 a 的默认拉取来源,也因此,一个本地分支同一时间只能跟踪一个远程分支。

让本地某分支跟踪远程分支的命令

$ git branch -u [REPO_NAME]/[REMOTE_BRANCH_NAME] [BRANCH_NAME]
// git branch -u binRepo/master binbin

2.协助者

  • 克隆成员远程仓库
  • 在 master 分支基础上创建自己的分支 member*
  • 在自己的分支上修改代码
  • 合并到 master 分支后推送到成员远程仓库
$ git clone https://coding.net/chenbin/GitTest2.git
$ git checkout -b member1;
        //…                                                       //修改代码
$ git add .
$ git commit -m"我帮你把XX功能完成了"
$ git checkout --no-ff merge member1;
$ git push

http://www.cnblogs.com/tangyikejun/p/4217561.html
时间: 2024-08-17 17:01:36

Git 在小团队中的管理流程(转)的相关文章

Home Contact Gallery RSS Git 在团队中的最佳实践--如何正确使用Git Flow

我们已经从SVN 切换到Git很多年了,现在几乎所有的项目都在使用Github管理, 本篇文章讲一下为什么使用Git, 以及如何在团队中正确使用. Git的优点 Git的优点很多,但是这里只列出我认为非常突出的几点. 由于是分布式,所有本地库包含了远程库的所有内容. 优秀的分支模型,打分支以及合并分支,机器方便. 快速,在这个时间就是金钱的时代,Git由于代码都在本地,打分支和合并分支机器快速,使用个SVN的能深刻体会到这种优势. 感兴趣的,可以去看一下Git本身的设计,内在的架构体现了很多的优

小团队管理与大团队管理

  我们公司和大部分传统软件公司一样,随着业务的发展和新领域的开拓,公司的管理风格越来越像华为,这是不是最佳的演进路线,我觉得值得探讨,以下是我的思考,希望跟大家讨论. 一个问题 前段时间跟一个创业的朋友聊天,说起他们最近在做的一个项目,这是一个教育行业的管理系统,业务非常复杂,牵涉到的决策人,需要对接的系统也非常多,最后问到他们做了多久完成这个项目,朋友告诉我2个多月,6个人,其中还括一个美工,一个项目经理:剩下的都是开发人员,没有测试,没有前端开发:朋友问我,如果这个项目给你们做,你们需要做

浅谈关于seo团队的管理流程

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 seo不是一个人的工作.这句话不知在哪里看到的,觉得很经典.现在的网络公司,都是团队操作,也有很多工作室,3-5人,很多很多.他们不再是seoer,而是seoers了.任何公司,任何团队,超过3个人,就一定存在一个问题,那就是管理~!管理做不好,团队的力量肯定发挥不出来.有些人seo技术很强,在团队中独当一面,我们需要这些人,团队里有这样的一

团队中的 Node.js 具体实践

前天,我们公司前端团队的几个人一起去大搜车参加了芋头所组织的「搜车 Node Party」.这是我第一次参加与 Node.js 相关的线下聚会,如果不算「杭JS」的话. 聚会现场 这次聚会的主题全部是与大搜车现行的业务和技术挂钩的:芋头讲述了团队中 Node.js 的技术演进及未来展望;死月分析了几个常用 ORM 的特点并安利了自己的作品;Plusman 分享了日志监控方案和实践.(相关演示文稿可以到芋头所写的总结中下载) 整场下来,虽说没有醍醐灌顶,但对我们团队接下来要做的事情还是比较有借鉴意

开发项目中如何管理版本有关的挑战

具体地讲,本文将讨论多个与如何管理版本有关的挑战,还将介绍为了提高生产力和质量而引入的一些变更. 在 14 个月的服务活动中,我与多个团队的成员合作过,不断增强现有流程,最大限度地提高开发团队的生产力,并满足客户为大型 Web 应用程序而设定的所有预期,这个 Web 应用程序是客户在竞争异常激烈的行业中取得全面成功的关键.该应用程序的实际用途对本讨论并不重要,我只想分享一下我在领导一个团队不断向业务关键型应用程序提供版本时学到的一些经验. 我的这个开发团队包括 7 位开发人员.1 位业务分析师.

互联网产品需求管理:产品管理流程

  对于互联网公司而言,产品需求管理是产品研发的核心环节,产品需求的正确与否直接影响产品开发周期.产品开发成本.产品运营成本,甚至直接决定了产品市场竞争力.根据统计:产品开发中40%-60%的问题都是在需求阶段埋下的"祸根" ,在测试阶段及运营阶段发现需求阶段植入的问题,解决的代价是需求阶段发现问题的68-200倍.      关于需求管理的故事很多,列举一些常见问题: 某天老板问起:我很久以前提过一个需求,提过以后就没下文了.产品经理无辜地说:有提过吗,是给我提的吗? 某个销售谈起:

如何在技术团队中推行OKR

OKR(Objectives & Key Results)是一种行之有效的目标管理方法,最早由Intel提出,后来被Google运用的炉火纯青,最终取得斐然成就.最近几年,越来越多的硅谷创业公司把OKR作为团队文化的基石.而在国内,虽然在不少知名互联网公司也在推行(如阿里巴巴),但其呼声却一直不如国外那么大. 我在一次偶然的机会阅读了<OKR:源于英特尔和谷歌的目标管理利器>这本书之后,便决心在团队中推行. 在推行OKR之前,我们已经在使用GitLab管理代码.里程碑和Issue.但遇

小团队拥有大能量 三十个年轻人的创业故事

当以天猫"双11"为主的网购盛宴被缔造,消费者狂欢的背后,众多电商企业也正在前所未有的发展.从某种意义上说,电商在一定程度上打破了地域的限制,催生了一定的消费能力,但是,电商本质上带来的,是消费者资源的重新分配.在当前环境下,"客户资源"可谓是电商企业在发展过程中需要抢夺的最核心资源,也是命脉所在.随着供应链等环节的成熟,传统的以货物为中心的运营模式,随之向以客户资源为中心的运营模式上转变.而在这种转型中,客户关系管理(CRM)就成为了电商企业的一把利器. 从电商业

MBTI在软件开发团队中的应用

人绝不是一种资源.一方面我们不可能因人设岗,另一方面也不能忽略人性的差异.面对问题时,不要总是单纯地从人的态度或品德上查找问题,而是要反思人事安排和流程建设上的不足.奢望一个人改掉他的缺点,还不足充分发挥他的优点. 前言 MBTI将人区分为16类人格特质,我无法断言是否真得能表达出人的真实一面,毕竟只是统计性的结果.我的思考并不在于它归类的结果,而在于它的归类方法.   在团队合作中,各种各样的情绪.喜好.偏见一直在影响着我们对于人和事的判断.我们强调第一印象的重要性,正是因为一旦被贴上标签,就