团队Git实践方案-Git工作流

Sophie_U

已于 2022-11-04 11:58:41 修改

阅读量664

点赞数 1

分类专栏：规范文档文章标签： git github

于 2019-12-17 21:23:48 首次发布

原文链接：https://www.jianshu.com/p/ef8c683d678d

版权

规范文档专栏收录该内容

5 篇文章 0 订阅

订阅专栏

在团队协作中，好好地应用 Git可以为团队开发带来更高的效率收益，也能保证整个工作流的完整推进。本文通过参考多篇优秀的Git实践文章总结而成，旨在为使用GIT标准分支开发流程的开发团队新人提供一份参考指南

一、一些好的习惯

1.1 提交

提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低；
不要每提交一次就推送一次
用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方

1.2 推送

当自己一个人进行开发时，在功能完成之前不要急着创建远程分支。

1.3 合并

在将其他分支的代码合并到当前分支时，如果那个分支是当前分支的父分支，为了保持图表的可读性和可追踪性，可以考虑用git rebase来代替git merge；反过来或者不是父子关系的两个分支以及互相已经git merge过的分支，就不要采用git rebase了，避免出现重复的冲突和提交节点。

二、常用操作命令简介

常用命令如下：

# 提交
git commit
# 添加跟踪
git add [--all]
# 推送
git push
# 拉取
git pull
# 分支操作
git branch [-d]
# 合并
git merge
# ”挑拣”提交
git cherry-pick
# 检出分支
git checkout [-b] BRANCH_NAME
# 暂存
git stash

更多命令参考： Git常用命令详解

三、分支管理

说到分支管理，就需要知道Git Flow分支模型，它定义了Git分支的一个规范，参照这个模型，可以应用于大部分工程场景

Git Flow 分支模型：能够应对 99% 的场景，剩下的那 1% 留给几乎不存在的极度变态的场景。
注意：它只是一个模型，而不是一个工具；你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。

简单说来，Git Flow 就是给原本普普通通的分支赋予了不同的「职责」：
项目中长期存在的两个分支(主要分支)：
- master：主分支，负责记录上线版本的迭代，该分支代码与线上代码是完全一致的。
- develop：开发分支，该分支记录相对稳定的版本，所有的feature分支和bugfix分支都从该分支创建。
其它分支为短期分支，其完成功能开发之后需要删除（派生分支）：
- feature/*：特性（功能）分支，用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 develop 分支，之后删除该分支。
- bugfix/*：bug修复分支，用于修复不紧急的bug，普通bug均需要创建bugfix分支开发，开发完成自测没问题后合并到 develop 分支后，删除该分支。
- release/*：发布分支，用于代码上线准备，该分支从develop分支创建，创建之后由测试同学发布到测试环境进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完后，在上线之前，需要合并该release分支到master分支和develop分支。
- hotfix/*：紧急bug修复分支，该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug，修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分
主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个

3.1 工具

好的工具可以方便开发操作，这里推荐SourceTree，它有一个创建Git Flow工具流选项，可以快速在工程中创建对应分支并管理。当然，也可以走命令行路线来创建Git Flow，参考文章：研发团队GIT开发流程
 下载地址：注意安装过程可能需要科学上网

3.2 工具与实践

按下command , 或ctrl ,调出「Preferences」界面并切换到「Git」标签，勾选「Use rebase instead of merge by default for tracked branches」([对提交分支默认使用变基代替合并])和「Do not fast-forward when merging, always create commit」（【合并时不要使用快进方式，总是创建提交】）

在这里插入图片描述

这样设置之后，在点「Pull」按钮拉取代码时会自动执行git pull --rebase；并且，每次合并时会自动创建新的包含分支信息的提交节点。
接下来，点击工具栏中的「Git Flow」按钮将相关的流程自动化。如果没有特殊需求，直接按下对话框中的「确定」。初始化完成后会自动切换到 develop 分支。
分支权限设置: 对于master 和 develop 分支，需要进行保护，只有项目负责人有权推送和删除。

3.3 开发功能

在确定发布日期之后，将需要完成的内容细分一下分配出去，负责某个功能的开发人员利用 SourceTree 所提供的 Git Flow 工具创建一个对应的 feature 分支。如果是多人配合的话，创建分支并做一些初始化工作之后就推送创建远程分支；否则，直到功能开发完毕要合并进 develop 前，不要创建远程分支。
功能开发完并自测之后，先切换到 develop 分支将最新的代码拉取下来，再切换回自己负责的 feature 分支把 develop 分支的代码合并进来。合并方式参照上文中的「合并」，如果有冲突则自己和配合的人一起解决。
然后，到 GitLab 上的项目首页创建合并请求（merge request）。
「来源分支」选择要被合并的 feature 分支且「目标分支」选择 develop 分支后点击「比较分支」按钮，在出现的表单中将处理人指派为项目负责人。
项目负责人在收到合并请求时，应该先做下代码审核(Code Review)看看有没有明显的严重的错误；有问题就找负责开发的人去修改，没有就接受请求并删除对应的 feature 分支。