Skip to content

tiev plus协作工作流（来源于gitlab）

Jump to bottom
johnzjq edited this page Mar 21, 2023 · 2 revisions

注意： Please execute git config remote.origin.prune true for your local clone !!!

介绍

tiev-sim 采用 feature branch workflow。

  • 首先， master 分支包含经过周密测试的最稳定代码。
  • develop 分支基于 master 进行演化， 用于进行联合调试和联合测试。
  • 在基于相对完整和稳定的 develop 分支上， 演化出7个固定的功能模块(包括 high_performance_server，distributed_server， benchmark, api, front_end)， 由各组开发成员进行开发，在这些分支上，开发者只能通过 Pull Request 的方式而不能通过 Push 的方式提交更新，以避免错误提交带来的负面影响。
  • 最终在功能模块的基础上，开发者们可以构建日常最常用的特性分支（feature branch)，并在这些分支上完成开发工作。 开发完成后，分支下游的改动逐层上传，上游集成各模块并处理各模块的冲突后，下游又拉取(pull)并迭代开发。 整个过程是异步进行的，模块之间的耦合较轻，效率和稳定性平衡较好。 分支演化的一个简易的示例如下所示：
master
├── hotfix
│   ├── hotfix_issue_123
│   └── ... 
└── develop
    ├── high_performance_server
    ├── distributed_server
    ├── benchmark
    ├── API
    |   └── ROS
    |   |   └── ROS 1.x
    |   |   └── ROS 2.0
    |   └── CyberRT
    |   └── ...
    ├── front_end
    │   └── judge_client
    |   └── observer_client
    ├──...

注意 在已有的稳定版本master分支上发现了未预料的BUG，可从hotfix分支上创建新的hotfix_issue_123分支。

注意 请大家严格遵守分支命名的示例规范，这样在使用时可以通过关键字在大量的分支中进行快速筛选，这需要所有人在命名习惯上的支持。 好的命名： slam_odometry planning_routing vision_parking_slot，不好的命名：vision_ParkingSlot planning_suduguihua issue_temp 60-zcm.

参考工作流

工作流简介

本项目采用敏捷开发的基本工作流程，利用issue进行开发活动的管理。

  • 首先，开发一个新功能前必须先撰写issue，内容采用feature模板，并对issue设置合理的Label (模块归属，讨论，ToDo等) 和计划的Due date（参考Milestone，可不完全一致）
  • issue划分的参考准则是在较短的时间内<4周可完成的功能，较大的issue作为Epic或者进行拆分
  • 其次，每周讨论将合理的issue分配到Doing并由Maintainer分配developer处理该issue
  • Maintainer或者一名负责该issue的developer从该issue创建merge request或创建branch，并选择正确的目标分支 (包括 common, slam， vision, lidar, prediction, planning 和 control)
    • merge request 会直接创建一个WIP merge request，并且创建一个该issue的远端分支，WIP表示该merge request还未完成
    • create branch 会创建一个该issue的远端分支
  • 所有处理该issue的developer在本地创建该issue的远端分支的跟踪分支，直接在该分支上进行工作；或者继续创建该跟踪分支的子分支，完成子分支工作后merge到该跟踪分支上
  • 完成工作后，maintainer负责处理该issue的merge request
  • 模块分支 (包括 common, slam， vision, lidar, prediction, planning 和 control) 定期由Maintainer负责提出合并到develop分支的Merge request

工作流示意

  1. 克隆项目:

    git clone https://gitlab.com/tjiv/tiev-plus.git

  2. 从ISSUE创建工作分支

    • 打开想要工作的issue，点击issue右侧的Create merge request右侧的下拉按钮，命名该分支名$MODULE_$FEATURE，并选择该分支所基于的分支$MODULE，即从 common, slam， vision, lidar, prediction, planning, control 和 hotfix（用于修复新发现的BUG） 中选择一个.
    • 然后创建分支

    image

  3. 切换到所创建的模块分支

    git fetch origin
git checkout -b $MODULE_$FEATURE origin/$MODULE_$FEATURE
# 同一个分支上合作的人数通常不超过3人

  4. 写代码， 提交(commit)修改:

    git status # 查看变动文件
git add . # 添加所有修改的文件到暂存区
git commit -am "功能实现了一点了"
git commit -am "功能又实现了一点了"
git commit -am "功能快实现了"
git commit -am "功能实现了"

  5. 解决与上游最新版本代码的冲突，并推送(push)分支到 GitLab:

    git pull # 远端分支合并，可能要处理conflict
git merge origin/$MODULE # 上游分支合并，可能要处理conflict [10月18日更新]
git push origin $MODULE_$FEATURE

  6. 在GitLab页面上查看你的提交， 确认无误后点击网页上的按钮创建一个 merge request 到你对应的 $MODULE 分支.

    Screenshot_from_2020-03-16_18-02-40

    2020-03-16-19-27-54

    注意！如果你对于squash后的冲突处理感到麻烦，不勾选squash完全可以接受。

  7. 团队中负责上游分支的同学或老师将查看提交的代码，并将他们合并到上游分支或主分支.

  8. 通常，下游的分支应该在开始新一轮作业之前，先 pull & merge 上游分支的修改，以减少版本差异。 有时在功能分支基础上临时增加新的开发需求，临时分支可以不推送到远端，合并到功能分支后删除。

    git pull
git checkout $MODULE_$FEATURE
git merge origin/$MODULE # 上游分支合并，可能要处理conflict [10月18日更新]
# then start work on the current branch

  9. 在远端分支被 GitLab 删除后，本地需要使用 git remote prune origin 命令进行同步删除，否则还会在 git branch -a 命令下看到以前的缓存。

注意事项

1.develop分支下的Dockerfile、.gitlab-ci.yml、/module/CmakeList.txt这些内容尽量避免修改，如果需要在Docker环境中安装软件或库，找到文件中“# Final SetUp”，在该行上一行添加需要安装的库，这样可以让Docker从你修改的位置开始重新构建镜像。

2.需要提交代码到develop时，第一次合并develop分支的处理很重要，如果出现冲突，不属于自己的模块代码请保留develop分支内容。

3.提交merge申请前再pull一下develop分支，确保develop分支没有更新。

REFERENCES:

  1. Always start with an issue
  2. GitLab Feature branch workflow
  3. GitLab Flow
  4. GitLab Git Workshop
  5. Squash and Merge
  6. deleted branch still visible

Clone this wiki locally