你们平时开发是像 github 一样 fork 后再 clone 这个仓库开发？
还是 clone 原仓库，基于原仓库的 master 开一个分支开发？
我们项目几十号人，我给了他们 fork 权限，发现部分人是 fork 后进行开发的，一个月都没 pull 到原仓库了。
This topic created in 2115 days ago, the information mentioned may be changed or developed.
Supplement 1 · Sep 10, 2020
谢谢大家的回复，解决了我的疑惑~
 |
1
erwin985211 Sep 10, 2020  1
虽然我不太懂，但是你们开发前都不合并一下最新代码的吗，这样做你们是怎么合并代码上线的
|
 |
2
xmitman Sep 10, 2020 2
不需要 fork 吧，拉取原仓库代码，开发的时候每个人基于 master 主干 checkout 分支做开发
|
 |
3
aimaodeyuer Sep 10, 2020 3
|
 |
4
goodboy95 Sep 10, 2020 1
fork 的好处是能做代码审查，如果不放心他们的代码质量就 fork，提交的时候让他们提 merge request 。
如果没啥不放心的就直接 clone 吧。 |
 |
5
zaul Sep 10, 2020 1
拉取原仓库代码，开发的时候每个人基于 master 主干 checkout 分支做开发
|
 |
6
KuroNekoFan Sep 10, 2020
githubflow 加一个平行于 master 的 test/dev 分支
|
 |
7
swulling Sep 10, 2020 via iPhone 1
你要用 github，那就是 fork 多代码库加 pull request，或者多分支加 pull request
但是我个人更喜欢 gerrit 的 cr 模式 |
 |
8
floyda Sep 10, 2020 1
fork 就用 PR 的方式提交代码, 对审核者不太友好, 面临冲突的可能比较多.
如果人多, 不建议在同一个分支上并行开发, 这样相当于把解决冲突的任务分散到组员身上, XJB 乱改就不好了. 如果十几个人, 可以按功能划分 submodule 不 pull 那就是管理的问题了 |
 |
9
hakono Sep 10, 2020 via Android 1
又不是给开源项目贡献代码，fork 实在是太麻烦了
基本都是 clone 后建分支然后 pull request 如果不信任的话设置好权限和用户组就行了 |
 |
10
yungo8 OP @floyda 嗯，已经是很多子模块，冲突不大可以直接拉分支弄的。跨部门的多个项目，他们 fork 后不 pull 倒是问题不大，就是我找了挺久都没看到他们最新有提交代码，我都怀疑他们另起炉灶去搞了仓库，没想到是 fork 派生了
|
 |
11
ghostcode Sep 10, 2020 1
按照 git flow
|
 |
12
chendy Sep 10, 2020 2
自家项目还 fork 个啥，控制分支权限，主干分支必须 pr 就行了
|
 |
13
leopod1995 Sep 10, 2020
保持良好习惯，fork 之后的好处在于自己的 repo 想怎么玩怎么玩你
|
 |
14
xhinliang Sep 10, 2020
1. Git Flow
2. GitHub Flow 3. GitLab Flow 4. TBD 一般就这四种，三楼那个我觉得是不太规范的。 |
 |
15
j2gg0s Sep 10, 2020
https://nvie.com/posts/a-successful-git-branching-model/ 建议走 feature，在同一个 repo 开发就好
|
 |
16
itechify PRO master checkout 出 dev，dev 按需求名称和日期 checkout 出需求分支，相关人都在需求分支开发，不同需求不同分支，qa 时候用 dev 合并对应需求分支，qa 验证过合到 master，master 上生产，我司大致流程这样
|
|
17
yungo8 OP @erwin985211 我们是多个子工程独立的，只是有一个 common，所有子工程都放在一个仓库里而已。一般不会在 common 模块写东西，各个部门之间基本上不会有冲突，只部署自己的那个引用 common 模块的工程。
|
 |
18
gromit1337 Sep 10, 2020
我现在的公司一个版本一个分支的开发，现在已经不知道有多少个分支了，不敢说话🙊
|
 |
20
maichael Sep 10, 2020
其实没有本质上区别，你 fork 出来一个仓库其实也是一个分支，重点都还是看你们项目代码的主分支是怎么管理的。
|
 |
21
Cola98 Sep 10, 2020
clone 项目
check 分支 push 分支 这个样子 |
 |
22
whileFalse Sep 10, 2020
@aimaodeyuer 请问为什么部署的代码和 master 不是同一个分支呢？
我是想问，为什么不先把 release 合并到 master，然后依照 master 更新生产呢 / |
 |
23
c4fun Sep 10, 2020 1
分支本身的策略大家都说了很多，基本上大家都偏向于一个仓库，使用 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. 循环下一个迭代。 |
 |
24
VDimos Sep 10, 2020 via Android
用 gerrit
|
 |
25
sxlzll Sep 10, 2020
fork 是因为开源项目，肯定不能给所有人静默开写权限
内部项目那么麻烦干嘛 |
 |
26
yanue Sep 11, 2020
人多 多版本同时进行开发 按照 git flow 流程容易管理些
|
Select Language