This topic created in 2140 days ago, the information mentioned may be changed or developed.
小团队，大家用 git 协作的时候流程是怎么样的？
我们目前开一个仓库，权限已分配，大家都往一个库里怼，总感觉不太好。
希望了解下目前的主流是什么？ 这样一方面拥抱最佳实践，另一方面当员工离职的时候能够快速融入主流。
 |
1
GoLand Jul 1, 2020
GitHub Flow https://guides.github.com/introduction/flow/ ，简单易理解，好实施。
|
 |
2
wangxiaoaer OP @GoLand #1 每人 fork 一个仓库吗？
|
|
3
GoLand Jul 1, 2020  2
@wangxiaoaer 是的，每人 fork 一个仓库，各自仓库上建 branch，之后往主仓库提交 pull request，合并到主仓库 master 后部署上线就行了。
|
 |
4
vx Jul 1, 2020
|
|
5
wangxiaoaer OP @vx #4 多谢。
|
|
6
wangxiaoaer OP @GoLand #3 这样会不会导致仓库里面很多重名仓库（虽然在各自名下），explore 的时候很乱？
|
|
7
GoLand Jul 1, 2020
@wangxiaoaer 别人 fork 到自己的名下了，你又不用管别人的仓库。
|
 |
8
yEhwG10ZJa83067x Jul 1, 2020
|
 |
9
lewinlan Jul 1, 2020 via Android 1
小团队还用 fork ？迷
|
|
10
wangxiaoaer OP @lewinlan #9 不然呢？
|
 |
11
caviar Jul 1, 2020 via iPhone
没必要 fork，每个人都在自己的名字下开 branch 就行吧。例如 username/foobar 这类
|
 |
12
doublleft Jul 1, 2020
@wangxiaoaer #10 开分支 然后 rebase 呗，一天 10 个迭代，日清 20 个 bug 常事，难道每次都要 fork->MR 么
|
 |
13
GeruzoniAnsasu Jul 1, 2020 via Android
为什么往一个库里怼不好？ 又不是往一个分支怼
|
 |
14
undef404 Jul 1, 2020
github flow 里没说要 fork repo 啊?
|
|
15
wangxiaoaer OP @undef404 #14 是的，我刚开始下意识一位 PR 是跨库的，现在看来 PR 也可以在同一个库上面操作。
那现在的问题就是 在同一个库中，权限的控制了，比如 master 不能提交，有权限的人员可以接受、检查 pr 并合并到 master 分支，这个我需要去查一查 |
 |
16
weixiangzhe Jul 1, 2020 via Android
gitlab flow 吧 简单点
|
|
17
weixiangzhe Jul 1, 2020 via Android
git flow 好多东西用不上，release 分支啥的基本用不到， 结我们现在是 gitlab flow 加点 feature 和 hotfix 分支
|
 |
18
aabbcc112233 Jul 1, 2020
小团队整那么复杂干啥
|
|
19
wangxiaoaer OP 1
@aabbcc112233 #18 希望组员得到锻炼，防止他们跟时代脱节，否则离职找工作的时候发现别人都机械化了，自己还是拿个镰刀挥舞，无所适从。
|
|
20
aabbcc112233 Jul 1, 2020
@wangxiaoaer 小公司要的就是机动性，没必要用大公司那一套。在什么位置就要做什么样的事，照搬可能带来恶果。当然我不是在否定大公司的做法，是要有选择性的使用。
|
 |
21
dr1q65MfKFKHnJr6 Jul 1, 2020
@wangxiaoaer 新来的公司还在用 svn 。。。。8 、9 个人的团队，SVN 都当文件共享服务器在用。。
|
 |
22
adajoy Jul 1, 2020
@GoLand github flow 上是先部署，生产上验证没问题以后再合 master 。这样就有问题吧？ 1. 部署和合并间隔过久？ 2.多个 feature 如何处理？
|
 |
24
Mithril Jul 1, 2020
可以参考 Git Flow 。
本质上就是保护主线，确保每次在主线上的提交都是通过 PR 进来的，Review 和 CI 过的。 至于你 PR 是跨库提进来的，还是跨分支进来的都无所谓。 实际上根据团队情况灵活应对就行了。 缺点就是提 PR 的人需要根据情况不停解决 Merge Conflict 。但是这个问题是没法避免的，SVN 还是 Mercurial 还是什么其他的 flow 都没办法解决。只要多人开发就总会有冲突需要解决的。 |
 |
25
wulin Jul 1, 2020 1
一开始试验过每个人 fork 后再建分支，实践过程中发现太麻烦了
改成在主仓库建不同分支，master 只接受合并不可提交 所有冲突全部拒绝，个人本地 pull 最新代码处理好了冲突再提交，比较适合几个人的小团队。 |
 |
26
sarices Jul 1, 2020
小团队就不要 fork 了，没必要，浪费时间，锁定 master 分支就好
|
|
27
46Gnj0E0OBmad377 Jul 1, 2020 via iPhone
master 的 policy 设置好，CI 配好，每个人自己开分支发 PR 就可以了。
|
 |
28
gesse Jul 1, 2020
|
 |
29
frankkai Jul 1, 2020
|
|
30
frankkai Jul 1, 2020
功能起 feature 、发布起 release 、改 bug 起 hotfix
线上环境 master 、测试环境一个、拟生产环境一个 目前没遇到太大的问题 感觉还行 |
|
31
GeruzoniAnsasu Jul 1, 2020
我们目前的实践（ gitlab EE ）：
- protected: master 、R-* - 开发分支随便开，命名要求由 ci 维护者制定，但不做特殊要求。这条的意思是，我可以写前端 check 只在 fe/*分支上跑，那么自然所有的前端 feature 都需要带 fe/前缀 - 设置自动发布环境的 CI，T-* 分支会自动执行发布脚本发布到测试环境，意味着你想要做前后端集成测试，必须把 fe/*分支和 be/*分支都 merge 到一个 T-* 上，由于 T-*分支不设保护，所以任何人都能进行 merge 操作，方便前后端联调 - 规定 R-*和 master 分支只允许从 T-*分支合并，由于分支受保护，因此仅有 maintainer 可以合并，他们可以拒绝不合规的 MR;同时这些 MR 信息必须使用模板，填写相关看板任务并通过 check list - master 会集中所有主线修改，所有 feature 和修复优先进入 master 。当某个迭代周期结束后，产生该迭代的 release 分支 R-*，并且打上版本 tag 。 R-*分支只接受与该期迭代相关的修改 MR，如 bug 修复，该迭代结束日暂时没做完 delay 掉的 feature 等 - T-*分支的发布使用测试私钥签名，R-*分支使用生产私钥签名（与产品 license 相关） 其实只要用得熟练小团队也可以很完善很自动。一开始这个组三四个人的时候只有 master 、T-*、开发分支，现在全组大概 30 个人，也基本还是沿用以前的流程 |
 |
32
djoiwhud Jul 1, 2020 via Android
你可能是需要多开工程，而不是 fork pr 。小于 100 人的公司完全不需要 fork pr 流程。
|
 |
33
Erroad Jul 1, 2020 via iPhone
一般的团队感觉没有多库的必要，而且这种东西每个公司都不太一样，去了现学一会儿也就上手，有啥脱节不脱节的
|
 |
34
ClericPy Jul 2, 2020
以前一直走的老的 git flow, 就是单独项目开仓库, 功能分支自己 rebase 最后提 pr 然后等 review 再合并后面自动走 CI
然后去年突然看到楼主说的这种, 而且还好多文章 diss 我用过的那种, 到处充斥着 "时代变了" 的气息... 那些文章说的其实也是很有道理, 也是所有项目都在一个仓库, 然后开分支, 好处很明显是真的, 一次 make 全家受益 老了唉 |
 |
35
hhyvs111 Jul 2, 2020 via iPhone
开分支就好了，master 只合入
|
 |
36
gbin Jul 2, 2020 via Android
#3 说得对，可以参考 Angular 的开发 flow
|
Select Language