@unco020511 我想的也是这个策略. 我的疑问是 dev 修改合入 main 分支出现冲突时, 如何解决该冲突.
有两种处理策略:
1. dev 分支先 rebase onto main, 解决完冲突后提交 MR 或者 PR 给 main 分支(dev 和 main 历史清晰, 但是 dev 历史被重写).
2. dev 分支先 merge main 分支, 解决完冲突后提交 MR 或者 PR 给 main 分支(main 和 dev 历史会比较乱, 因为 dev 和 main 相互 merge).
不知道你们那边是如何处理的?

@rationa1cuzz 能否详细讲讲 tag 管理版本?

@swulling 开发分支合入主线后 rebase 主线会不会导致开发分支历史混乱呢？毕竟这是公共分支

@swulling 开发分支提交 mr 给主线有冲突要怎么解决呢？先 merge 主线再提 mr ？

@swulling 自动触发 git rebase master 将代码更新为最新，是针对已经合入 master 的开发分支，还是未合入的开发分支呢？

@swulling 我理一下你的意思，帮忙看下我说的对不对。
开发人员基于开发分支创建自己的功能分支，一旦某个 feature 完成开发后，先将功能分支 rebase onto 开发分支，然后已经 mr 给开发分支，合入后可以删除功能分支。继续从开发分支拉功能分支，继续下一个功能开发。
等待开发分支上合入了所有特性，并且测试通过，基于开发分支直接提交一个 mr 给主干，主干审核通过后会自动触发开发分支 rebase onto 主干分支。

@andyJado 这个意思啊。github 好像用 fork 多一些，gitlab 倾向于分支。fork 的话还是会有我说的疑问，dev 如何回到 master 。

@andyJado 这个适用于拆分功能模块吧。

请教下，我指的是 dev rebase onto master ，这个对 dev 分支来说会破坏共识吧？ dev 分支对一个项目的成员来说是公共分支。

@corningsun 不同团队开发可以用不同的 dev 分支, 但是开发完成要统一合回 master 分支. 这就导致第二个及之后合回 master 分支的 dev 分支肯定不能达到 fast-forward 要求, 这时候要么做 rebase, 要么做 merge, 之后才能提交 PR 给 master 分支.

到 master 可以直接 merge ，没必要强制 rebase 的
-- 直接 merge 的话会导致 master 历史比较乱, 比如下面这种, 不利于后续维护, 比如想要单独回退某个 feature 的修改.
* 9f0c13b (HEAD -> master) feture-c finished
|\
| * 55be61c C.2
| * e18b5c5 merge master
| |\
| |/
|/|
* | ee549c2 feture-a finished
|\ \
| * | 51f2126 A.3
| * | 72118e2 merge master

想要的是类似下面这种历史:
v* e2e6451 (HEAD -> master) feture-c finished
|\
| * 516fc18 C.2
| * 09112f5 C.1
|/
* c6667ab feture-a finished
|\
| * e64c4b6 A.2
| * 6058323 A.1
|/

@mickerwx 我的需求比较像你说的 功能分支 工作流, 但是 新分支 如何合回主线, 这是我的疑问点.
因为 git 是基于 snapshot 去管理文件的, 不像 svn 是基于 diff(差异)的, 就会导致不做 rebase 进行 merge 的 master 历史非常乱(master 历史上会有关于同一个修改的重复历史).
如果用 squash , 又会丢失原作者的信息.

@lonely701 感谢建议, 最终买了二手超微主板自己 DIY.

@jim9606 嗯, 当前了解到 tailscale 和 netmaker 都可以做这个事.

找到个类似 tailscale 的软件, netmaker.

@OOKAMI 简单看了下功能, 猜测是用 tailscale 的公共服务器实现了 wireguard 配置自动交换?

@SgtPepper 了解下, 多谢.

@digimoon 了解下,多谢.

@mythabc 多谢分享.
请问一套下来多少 R? 12 代 CPU 兼容性怎么样, 用什么系统做宿主机的?

@powergx 有推荐的整套配套吗?