git 搞分支的问题

[yeqizhang]

你们平时开发是像 github 一样 fork 后再 clone 这个仓库开发？

还是 clone 原仓库，基于原仓库的 master 开一个分支开发？

我们项目几十号人，我给了他们 fork 权限，发现部分人是 fork 后进行开发的，一个月都没 pull 到原仓库了。

[Cola98]

clone 项目
check 分支
push 分支
这个样子

[whileFalse]

@aimaodeyuer 请问为什么部署的代码和 master 不是同一个分支呢？
我是想问，为什么不先把 release 合并到 master，然后依照 master 更新生产呢 /

[c4fun]

分支本身的策略大家都说了很多，基本上大家都偏向于一个仓库，使用 git flow 的方式来拉分支。
一般一个月都没有 pull 的话，那是敏捷和 CI/CD 的思路没有贯彻好，这种比较容易出现各种合并冲突，并且也不利于问题的早期发现。
1. 建议 2~4 周一个迭代，每一个迭代开始，就取一个类似于 sprint-001 这样的分支作为主开发分支，用户在这个迭代主分支上面拉 feature 分支开发，并且基本每个 feature 完成之后都要合并到 sprint-001 中（可以用 github action 来做 CI，这样实现每次提交自动触发流水线，及时发现问题）
2. 要发布的时候，可以拉出一个对应的 release 分支，可以在这个分支上面维护 release_note 等。
3. release 分支正式发布之后，合并回 master 分支，同时打 tag 。
4. 循环下一个迭代。

[VDimos]

用 gerrit

[sxlzll]

fork 是因为开源项目，肯定不能给所有人静默开写权限
内部项目那么麻烦干嘛

[yanue]

人多 多版本同时进行开发 按照 git flow 流程容易管理些