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-11-08 08:18:17

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

Git在商业项目中的使用流程

一 引言这一篇文章还是记录我在杭州工作的总结. 我刚来公司的时候,对Git的使用很头痛,因为在学校里面很少用这个东西,即使用,一般也只有一个分支,不会出现代码冲突和代码合并的情况.但是公司里面一个项目组有那么多的人,无法避免代码冲突和合并.从开始的战战兢兢到后来教新人使用Git,也算是一个成长吧,记录一下我总结的使用方法. 二 关于冲突 公司里面用的是GitLab,其实和GitHub是一个道理.在团队协作时,合并代码的过程中出现冲突时非常正常的一件事,并不是错误.所以也不要害怕冲突,更不能试图掩

基于git的软件开发中并行工程管理以及版本控制系统概要

并行工程师什么,这里就不再解释(不懂请百度),实际上,在软件开发过程中,涉及到多人合作的以项目小组形式完成开发的软件(这里指广义上)或多或少都使用了并行工程的概念,在正式的项目开发中,项目小组成员总是分工合作每人完成一部分,然后再合并起来,而且,在实际应用中,尽管使用的是瀑布模型完成开发,但总是所有项目小组成员同时开始完成自己的部分,这,其实已经是并行工程了,我们可以自豪的宣布:我们在开发过程中使用了并行 工程这种高大上的玩意来提高开发速度,所以,老板你得给我们涨工资! 很简单吧,看起来好简单的

小团队管理与大团队管理

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

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

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

《大产品,小团队——携程敏捷技术与管理转型实战》读后感

作为曾经携程的一员,看到一起奋斗过的小伙伴们宣传此书立刻就买了,非常开心拿到了作者团队的亲笔签名版.读完颇为感慨与惭愧,有种虽然身在此山中,竟不识庐山真面目的感受.当时身处携程俩大核心业务之一,却只知一味地吐槽糟糕的流程和无止尽的加班,即没有推动改进的勇气与执行力,也不知背地里整个公司为优化流程,提倡创新所作出的努力,以及已经取得的成果. 诚如书名<大产品,小团队——携程敏捷技术与管理转型实战>,此书着重于在敏捷开发与管理转型期碰到的问题与解决方案,所以建议小伙伴们在学过了ACP,或者敏捷项目

git入门(4)团队中git保管代码常用操作

在团队中协作代码时候,一定要熟练使用以下git命令,不至于把代码库弄乱, PS:一定要提交自己代码(git push)时候,先进行更新本地代码库(git pull),不然提交异常 git常用命令 1·.clone相应项目 git clone ... 举个栗子(只是个栗子) git clone https://github.com/saucxs/watermark.git 2.新建分支并且切换到这个分支 git checkout -b 分支名(英文名) git chenckout -b dialy

项目团队中4种组员类型的相应管理方式

在我们的实际软件项目中,管理团队其实比写代码或者实现一个客户的需求更为的有挑战性.因为编程实际上是和机器打交道,而和机器打交道,只要你符合机器预定的逻辑, 一步步迈向解决问题的道路上一点都不难,但是人确实动态变化的,因为人时时刻刻受到各种外部因素的影响.总之,我们可以把组内的人分成四种类型: 1.有意愿有能力 2.有意愿无能力 3.无意愿有能力 4.无意愿无能力 那么对这四种类型的团队成员如何进行管理呢? 1.对于第1种人,授权,充分的授权.比如让其协助管理团队里面的一些事情. 2.对于第2种人

git开发过程中的使用流程

001.创建仓库 002.新建项目 003.初始化仓库  这一步不需要做 git init : 文件夹中会多出一个隐藏的.git文件 004.克隆项目 git clone <项目地址> 005.编写代码并提交到github上面 1.git add index.html 2.git commit -m "主分支提交" 3.git push 006.在github上面查看文件的变动 007.多人协作开发(接下来用张三.李四.CTO三人来演示工作中的流程) 1.张三克隆文件:gi

小程序全局状态管理,在页面中获取globalData和使用globalSetData

GitHub: https://github.com/WozHuang/mp-extend 主要目标 微信小程序官方没有提供类似vuex.redux全局状态管理的解决方案,但是在一个完整的项目中各组件的数据一致性是必须要保证,因此需要开发一个能够实现小程序全局状态管理的解决方案. 设计思路 参考omix后,我觉得其中实现全局状态管理的方式与小程序本身的写法有点差异 小程序使用setData,omix直接使用封装的this.store修改 小程序官方的示例中以app.globalData作为全局属