Git工作流（随笔）

目录

前言

一、工作流概述

1、概念

2、分类

二、集中式工作流

1、概述

2、介绍

3、操作过程

三、功能分支工作流

1、概述

2、介绍

3、操作过程

1）创建远程分支

2）删除远程分支

四、GitFlow工作流

1、概述

2、介绍

 

3、操作过程

五、Forking工作流

1、概述

2、介绍

3、操作过程

扩展

Pull Requests

总结

---

前言

Git工作流是指在团队中使用Git进行协作开发时，各个成员遵循的一套代码管理和版本控制的规范流程

一、工作流概述

1、概念

通俗的讲，GIt工作流指的是代码管理的工作流程和方式。在实际的工作中，根据不同的场景，使用不同的工作流方式。

2、分类

1. 集中式工作流
2. 功能分支工作流
3. GitFlow工作流
4. Forking工作流

二、集中式工作流

1、概述

集中式系统中通常使用的是单点协作模型——集中式工作流。 一个中心集线器，或者说 仓库，可以接受代码，所有人将自己的工作与之同步。 若干个开发者则作为节点，即中心仓库的消费者与中心仓库同步。

2、介绍

所有成员都将代码推送到同一个远程仓库中，通常由一个主要的分支（如master）作为代码的主线。这作流适用于小型团队或个人项目，操作简单，但缺乏灵活性。

 如果两个开发者从中心仓库克隆代码下来，同时作了一些修改，那么只有第一个开发者可以顺利地把数据推送回共享服务器。 第二个开发者在推送修改之前，必须先将第一个人的工作合并进来，这样才不会覆盖第一个人的修改。 这和 Subversion （或任何 CVCS）中的概念一样，而且这个模式也可以很好地运用到 Git 中。

3、操作过程

1. 项目维护者推送到主仓库。
2. 添加仓库成员
3. 贡献者克隆此仓库，做出修改。
4. 贡献者将数据推送到仓库。

三、功能分支工作流

1、概述

功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在 master 分支上。这个隔离可以方便多个开发者在各自的功能上开发而不会弄乱主干代码。另外，也保证了 master 分支的代码一定不会是有问题的，极大有利于集成环境。

2、介绍

每个功能或任务都在自己的分支上进行开发，当完成后再将分支合并到主分支上。这作流适用于大型团队或复杂项目，可以更好地管理代码的版本和变化。

功能开发隔离也让 pull requests 工作流成功可能，pull requests 工作流能为每个分支发起一个讨论，在分支合入正式项目之前，给其它开发者有表示赞同的机会。另外，如果你在功能开发中有问题卡住了，可以开一个 pull requests 来向同学们征求建议。这些做法的重点就是，pull requests 让团队成员之间互相评论工作变成非常方便！

3、操作过程

1. 项目维护者推送到主仓库。
2. 添加仓库成员
3. 贡献者克隆此仓库，在每次开始新功能前先创建一个功能分支，并实现相关的操作。
4. 贡献者将数据推送到自己的仓库，并发起pull requests，请求合并
5. 维护者在自己本地的仓库中，将贡献者的仓库加为远程仓库并合并修改。
6. 维护者将合并后的修改推送到主仓库。

 功能分支除了可以隔离功能的开发，也使得通过 Pull Requests 讨论变更成为可能。一旦某个开发完成一个功能，不是立即合并到 master，而是 push 到中央仓库的功能分支上并发起一个 Pull Request 请求去合并修改到 master。在修改成为主干代码前，这让其它的开发者有机会先去 Review 变更。

1）创建远程分支

即，在本机上创建分支，然后再推送到远程主机

# 基于指定的本地分支来创建的远程分支
$ git push <远程主机名> 本地分支名称:远程分支名称

# 基于master,创建远程分支testing
$ git push origin master:testing

2）删除远程分支

$ git push <远端> :远程分支名称
$ git push <远端> --delete 远程分支名称

$ git push yaya :test02
$ git push yaya --delete test02

四、GitFlow工作流

1、概述

GitFlow 工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。

2、介绍

GitFlow 工作流：该工作流程在功能分支工作流的基础上增加了发布分支和维护分支。发布分支用于准备发布版本，维护分支用于修复生产环境中的bug。该工作流适用于需要频繁发布版本的项目。

GitFlow 工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。除了使用功能分支，在做准备、维护和记录发布也使用各自的分支。当然你可以用上功能分支工作流所有的好处：Pull Requests、隔离实验性开发和更高效的协作。

以下是不同分支的命名规范：

3、操作过程

1. 项目维护者推送到主仓库。
2. 添加仓库成员
3. 贡献者克隆此仓库，在每次开始新功能前先创建一个功能分支，并实现相关的操作。
4. 贡献者将数据推送到自己的仓库，并发起pull requests，请求合并
5. 维护者在自己本地的仓库中，将贡献者的仓库加为远程仓库并合并修改。
6. 维护者将合并后的修改推送到主仓库。

五、Forking工作流

1、概述

Forking 工作流和前面讨论的几种工作流有根本的不同。这种工作流不是使用单个服务端仓库作为『中央』代码基线，而让各个开发者都有一个服务端仓库。这意味着各个代码贡献者有 2 个 Git 仓库而不是 1 个：一个本地私有的，另一个服务端公开的。

2、介绍

Forking工作流：每个开发者都从远程仓库中fork一个副本，并在自己的副本上进行开发。当开发完成后，通过pull request向原仓库提交代码。这作流适用于开源项目或跨组织合作的项目。

Forking 工作流的一个主要优势是，贡献的代码可以被集成，而不需要所有人都能 push 代码到仅有的中央仓库中。开发者 push 到自己的服务端仓库，而只有项目维护者才能 push 到正式仓库。这样项目维护者可以接受任何开发者的提交，但无需给他正式代码库的写权限。 

效果就是一个分布式的工作流，能为大型、自发性的团队（包括了不受信的第三方）提供灵活的方式来安全的协作。也让这个工作流成为开源项目的理想工作流。

3、操作过程

1. 项目维护者推送到主仓库。
2. 添加仓库成员
3. 贡献者克隆（Forking）此仓库，做出修改。
4. 贡献者将数据推送到自己的公开仓库。
5. 贡献者给维护者发送邮件，请求拉取自己的更新。
6. 维护者在自己本地的仓库中，将贡献者的仓库加为远程仓库并合并修改。
7. 维护者将合并后的修改推送到主仓库。

扩展

Pull Requests

"Pull Request 是一种通知机制。你修改了他人的代码，将你的修改通知原来的作者，希望他合并你的修改，这就是 Pull Request。"

Pull Request 本质上是一种软件的合作方式，是将涉及不同功能的代码，纳入主干的一种流程。这个过程中，还可以进行讨论、审核和修改代码

 Pull Request  可以和功能分支工作流、GitFlow 工作流或 Forking 工作流一起使用。但 Pull Request 要求要么分支不同，要么仓库不同，所以不能用于集中式工作流。在不同的工作流中使用 Pull Request 会有一些不同，但基本的过程是这样的：

1. 开发者在本地仓库中新建一个专门的分支开发功能。
2. 开发者 push 分支修改到公开的 Bitbucket 仓库中。
3. 开发者通过 Bitbucket 发起一个 Pull Request。
4. 团队的其它成员 review code，讨论并修改。
5. 项目维护者合并功能到官方仓库中并关闭 Pull Request。

总结

以上几种Git工作流各有优缺点，选择适合自己的工作流需要根据项目的规模、团队人数、开发方式等因素进行考虑，然后选择合适的！