# opensource

**Repository Path**: aubo-nxrobo/opensource

## Basic Information

- **Project Name**: opensource
- **Description**: 移动复合机器人科研相关
第三方工具库（AI、视觉、末端执行器、传感器、算法库等）
- **Primary Language**: Unknown
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2024-04-12
- **Last Updated**: 2024-09-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# opensource

#### 介绍
移动复合机器人科研相关
第三方工具库（AI、视觉、末端执行器、传感器、算法库等）

# gitlab-flow分支模型

<!-- toc -->

## 1 分支模型

参考[阮一峰的教程](http://www.ruanyifeng.com/blog/2015/12/git-workflow.html)

[Gitlab flow](http://doc.gitlab.com/ee/workflow/gitlab_flow.html) 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 `gitlab.com` 推荐的做法。

### 1.1 上游优先

Gitlab flow 的最大原则叫做**"上游优先"(upsteam first)**，即只存在一个主分支`master`，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。

[Chromium项目](https://www.chromium.org/chromium-os/chromiumos-design-docs/upstream-first)就是一个例子，它明确规定，上游分支依次为：

> 1\. Linus Torvalds的分支
> 2\. 子系统（比如netdev）的分支
> 3\. 设备厂商（比如三星）的分支

### 1.2 持续发布

Gitlab flow 分成两种情况，适应不同的开发流程。对于"持续发布"的项目，它建议在`master`分支以外，再建立不同的环境分支。比如，"开发环境"的分支是`master`，"预发环境"的分支是`pre-production`，"生产环境"的分支是`production`。
![输入图片说明](https://foruda.gitee.com/images/1726106448677879047/a140d37c_80341.png "屏幕截图")

开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到`master`，确认没有问题，再`cherry-pick`到`pre-production`，这一步也没有问题，才进入`production`。

只有紧急情况，才允许跳过上游，直接合并到下游分支。

### 1.3 版本发布

![输入图片说明](https://foruda.gitee.com/images/1726106473527121068/dcc24351_80341.png "屏幕截图")

对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从`master`分支拉出一个分支，比如`v2.3-stable`、`v2.4-stable`等等。以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。  
团队协作开发时，一般都是基于`master`分支进行，也就是`rebase`操作时的基准为`master`，并且提交合并请求时的目标分支也为`master`

`next`分支：下一个稳定分支，可能存在一些`bug`，当前团队会有部分为基于此分支进行开发。  


版本规范参考: [语义版本规范](bibliography/语义版本规范.md)

## 2 `git `开发流程

团队开发中，遵循一个合理、清晰的Git使用流程，是非常重要的。

否则，每个人都提交一堆杂乱无章的commit，项目很快就会变得难以协调和维护。

![输入图片说明](https://foruda.gitee.com/images/1726106492119427577/aa665211_80341.png "屏幕截图")

### 2.1 ~~fork要参与开发的仓库(repository)~~

### 2.2 clone仓库到本地

> ```bash
> # 克隆仓库到本地，默认会添加一个名为origin的远程仓库
> git clone ssh://...
> ```

### 2.3 新建分支

首先，每次开发新功能，都应该新建一个单独的分支（这方面可以参考[《Git分支管理策略》](http://www.ruanyifeng.com/blog/2012/07/git.html)）。

> ```bash
> # 获取origin最新代码
> git fetch origin
> git checkout origin/master
>
> # 新建一个开发分支myfeature(名字根据需求来定，如bugfix/a)
> git checkout -b myfeature
> ```

### 2.4 提交分支commit

分支修改后，就可以提交commit了。具体可以参考 [02_cheatlist.md](02_cheatlist.md)

> ```bash
> git add .
> git status
> # 查看变更
> git diff
> # 提交变更
> git commit  
> ```

### 2.5 与主干同步

分支的开发过程中，要经常与主干保持同步。

> ```bash
> # git pull是git fetch和git merge两个步骤的结合, 图中第5步应该为git fetch
> git fetch origin master
>
> # 首先，git 会把 myfeature 分支里面的每个 commit 取消掉；
> # 其次，把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；
> # 然后，把 myfeature 分支更新到最新的 master 分支；
> # 最后，把上面保存的 patch 文件应用到 myfeature 分支上
> git rebase -i origin/master
> 
> 更加简化的指令为
> git pull --rebase origin master
> ```

分支开发完成后，很可能有一堆commit，但是合并到主干的时候，往往希望只有一个（或最多两三个）commit，这样不仅清晰，也容易管理。

那么，怎样才能将多个commit合并呢？这就要用到 `git rebase` 命令。参考[git rebase说明](http://jartto.wang/2018/12/11/git-rebase/)

> ```bash
> git rebase -i origin/master
> ```

`git rebase`命令的`-i`参数表示互动（interactive），这时git会打开一个互动界面，进行下一步操作。

`squash`和`fixup`命令，还可以当作命令行参数使用，自动合并commit。

> ```bash
> git commit --fixup  
> git rebase -i --autosquash 
> ```

这个用法请参考[这篇文章](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html)，这里就不解释了。

### 2.6 推送到远程仓库

合并commit后，就可以推送当前分支到你自己的远程仓库了。

> ```bash
> git push -u origin myfeature
> ```

### 2.7 发出Merge Request

提交到远程仓库以后，就可以发出 Merge Request 到主干分支，即`master`分支或者`next`分支，然后请求别人进行代码review，确认可以合并到master。  

### 2.8 同步bug-fix提交到其他稳定分支
> ```bash
> git fetch origin
> git checkout origin/vx.y-stable  
> git cherry-pick <commit-id>  # commit-id 为 master 或 next 等上游分支上的 commit
> 
> # 解决冲突
> 
> # 提交到远程，主要由于 vx.y-stable 分支为受保护的分支，无法直接提交，因此需要重新定义远程分支名字， fix-xxxx 可以随便取，只要不冲突即可
> git push origin vx.y-stable:fix-xxxx
> 
> # 提交合并请求到 vx.y-stable 分支
> 
> # 重复以上步骤，将新的bug修复commit合并到其他稳定版本分支
> ```