1. SVN集中式的版本控制系统,所有人的工作快照都存放在同一个地方
2. Git分布式的版本控制系统，Git每个人都有自己本地仓库，可以在自己的本地仓库提交更改。对于你自己的 电脑来说你使用的是集中式系统的开发方式，仓库中的所有更改都存放在自己的机器上。当你准备好自己的工作共享给别人时，链接到远程仓库，将自己的分支推送上去。

共同维护的模型

. 单个共享的仓库，每个人都拥有自己对仓库的共享写入权限，目前公司的模型
. 并列贡献者仓库的模型 。 上游保留了仓库的完整控制，决定谁拥有项目仓库的读写权限。贡献者克隆派生项目，修改副本后通过合并请求或拉去请求提交这些更改。

分支的策略的几种约定

1. 主线开发分支，项目的主分支应该只包含经过测试的工作，并且绝不应该被破坏
2. 功能分支和集成分支 所有新的工作都在一个功能分支上完成，这个分支的小到恰好能容纳一个完整的想法
3. 一些分支通过一个集成分支与其他开发者完成的工作保持同步。等到软件发布前，构建管理员可以挑选那些功能集成到这个版本。添加多个功能分支和一个集成分支后一直可以保证代码一直是可部署的

Gitflow
在理想的协作团队中，功能将在你开始的工作前在工单中进行描述，并且分支名会包含这个工单名。[ticket_id]-[terse-title] 命名约定。比如一个工单 “1234” ，功能时修改失效链接， 分支名分为 “1234-fixing_links”
最初，软件项目只有一个develop分支,在开发分支上添加新的功能，直到没有新功能需要做了，将这个时间点叫做功能冻结。此时会从开发分支上创建一个新的分支，只有Bug修复能提交到这分支上去。功能冻结是或许并不是所有功能都完成了，所以任然有工作被提交至develop分支，如果发现了Bug。这些bug同样需要被”向后”并入develop分支。
经过一段时间所有bug会被宣告发现修复。此时所有经过了指令保证测试的代码都被提交到master分支上。接着就可以部署了。

当然现实中有一些需要立即修改的Bug，需要从产品分支拉出一条新的分支，他不应该包含除了修复Bug以外的任何工作，当修完分这些Bug后，将分支合并到产品分支和开发分支。

更新分支
将基变解释为在一个已有的时间线上重放已有的提交
. rebase 命令用于更新分支
. merge 命令用于引入全新的工作

根据计划发布软件

1. 从一个基本的提交开始，创建一个master
2. 打上 v1.0的标签
3. 将代码推送到集中式代码托管系统

1，新建develop 分支，在develop 分支上进行产品的开发
2. 新功能的添加 创建功能分支
3. 完成开发后将develop分支并如qa测试分支
4. qa测试分支完成后将qa分支并入master分支，打上发布版本的标签

发布后的补丁

有时候部署的代码存在错误，如果这个bug需要在下次软件发布前得到快速修复，这时就需要一个计划外的修复，这些部署通常称为补丁。在补丁中，工作不是从develop分支开始，而是从maser分支开始，确保更改只引入了部署代码中发现的问题的修复

工作流
1. 创建一个新的补丁分支，通常以hotfix开头，迁出master分支而不是develop分支
2. 生成标签名的列表，定位到最新打上标签的发布
3. 从master 最新打上的标签发不上，创建一个新的分支 使用hotfix- 【工单号】 -【工单的描述】(hotfix-123-fix_error_links)
4. 修复bug
5. 将通过测试的补丁并入master分支
6. 将master分支上的最新提交打上最新发布的版本号，如v1.01
7. 将经过测试的补丁并入develop分支，保证下次软件正式分布的时候不会丢失

基本工作流

Gitlab 工单

1. 填写工单

基于 GitLab 的简单项目管理与协作流程)

编写优秀的“需求” issue
如果你要录入一个需求类的 issue，最好在内容主体中包含下面这些内容：

用一句话描述你的需求，并用它作为标题
这个需求是解决什么问题的？
这个需求对软件现有功能会造成什么影响？
这个需求应该实现什么样的功能？
这个需求是否依赖其他模块提供相关支持？
[可选] 这个需求有哪些实现方式？
[可选] 这些可选的实现方式分别有哪些优缺点？

编写优秀的“bug” issue
如果你要录入一个 bug issue，最好在内容主体中包含下面这些内容：

提供出现问题的软件版本号、操作系统环境等相关信息
提供能够稳定复现问题的相关步骤
描述期待行为与当前行为
[可选] 你对这个 bug 原因的相关分析

1. 开始一个工单时，在工单跟踪工具中更新状态，比如标记她正在进行，这会通知你的团队你正在进行的工作, 并且告诉你为了完成这个工单需要创建的分支数量

2. 从develop分支上创建一个命名包含工单编号和大致的工作描述的新分支
   

3. 在开始工作后，确保每次可能的更改并入master分支之前，工单分支能保持最新的状态。每次提交说明都包含以工单号的方括号开头:[#1234]

4. 运行相关测试，通过代码检查
5. 当你完成工作的时候上传最后一个提交，包含关键词resolves 后跟工单号： Resolves [#1234]
6. 用工单追踪工具为这个工单添加一个评论 比较描述证明已经完成该工单，如截图等
7. 确保工单分支保持最新，并将工作分支合并到develop分支，并将分支推送到远程中央仓库
8. 假设别无问题，关闭工单
9. 最后删除本地的工单分支以及这个工单分支的远程副本

Readme 概述项目
. 如果项目包含依赖，列出一依赖
. 如果有安装说明，则列出安装指南

如何保持分支最新
比如在develop分支上开发，上游develop分支已经更新
1. 本地 git checkout develop
2. git pull origin develop
比如你工作在某个工单分支feature/login，源分支为develop则需
1. git checkout feature/login
2. git rebase develop