git 搞分支的问题

[yeqizhang]

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

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

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

[erwin985211]

虽然我不太懂，但是你们开发前都不合并一下最新代码的吗，这样做你们是怎么合并代码上线的

[linxb]

不需要 fork 吧，拉取原仓库代码，开发的时候每个人基于 master 主干 checkout 分支做开发

[aimaodeyuer]

1.clone 原仓库
2.master 拉新开发分支
3.开发完了往 dev 固定分支合并测试
4.dev 通过后上 QA，开发分支合到 QA 的 release 分支测试
5.QA 验证通过，用 release 部署线上
6.master 回合 release
7.周而复始

[goodboy95]

fork 的好处是能做代码审查，如果不放心他们的代码质量就 fork，提交的时候让他们提 merge request 。
如果没啥不放心的就直接 clone 吧。

[zaul]

拉取原仓库代码，开发的时候每个人基于 master 主干 checkout 分支做开发

[KuroNekoFan]

githubflow 加一个平行于 master 的 test/dev 分支

[swulling]

你要用 github，那就是 fork 多代码库加 pull request，或者多分支加 pull request

但是我个人更喜欢 gerrit 的 cr 模式

[floyda]

fork 就用 PR 的方式提交代码, 对审核者不太友好, 面临冲突的可能比较多.
如果人多, 不建议在同一个分支上并行开发, 这样相当于把解决冲突的任务分散到组员身上, XJB 乱改就不好了.

如果十几个人, 可以按功能划分 submodule

不 pull 那就是管理的问题了

[hakono]

又不是给开源项目贡献代码，fork 实在是太麻烦了

基本都是 clone 后建分支然后 pull request

如果不信任的话设置好权限和用户组就行了

[yeqizhang]

@floyda 嗯，已经是很多子模块，冲突不大可以直接拉分支弄的。跨部门的多个项目，他们 fork 后不 pull 倒是问题不大，就是我找了挺久都没看到他们最新有提交代码，我都怀疑他们另起炉灶去搞了仓库，没想到是 fork 派生了

[ghostcode]

按照 git flow

[chendy]

自家项目还 fork 个啥，控制分支权限，主干分支必须 pr 就行了

[leopod1995]

保持良好习惯，fork 之后的好处在于自己的 repo 想怎么玩怎么玩你

[xhinliang]

1. Git Flow
2. GitHub Flow
3. GitLab Flow
4. TBD

一般就这四种，三楼那个我觉得是不太规范的。

[j2gg0s]

https://nvie.com/posts/a-successful-git-branching-model/ 建议走 feature，在同一个 repo 开发就好

[oneisall8955]

master checkout 出 dev，dev 按需求名称和日期 checkout 出需求分支，相关人都在需求分支开发，不同需求不同分支，qa 时候用 dev 合并对应需求分支，qa 验证过合到 master，master 上生产，我司大致流程这样

[yeqizhang]

@erwin985211 我们是多个子工程独立的，只是有一个 common，所有子工程都放在一个仓库里而已。一般不会在 common 模块写东西，各个部门之间基本上不会有冲突，只部署自己的那个引用 common 模块的工程。

[gromit1337]

我现在的公司一个版本一个分支的开发，现在已经不知道有多少个分支了，不敢说话🙊

[maichael]

@goodboy95 #4 切分支也一样可以 review 的。

[maichael]

其实没有本质上区别，你 fork 出来一个仓库其实也是一个分支，重点都还是看你们项目代码的主分支是怎么管理的。