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