这是一个创建于 1604 天前的主题，其中的信息可能已经有所发展或是发生改变。
小团队，大家用 git 协作的时候流程是怎么样的？
我们目前开一个仓库，权限已分配，大家都往一个库里怼，总感觉不太好。
希望了解下目前的主流是什么？ 这样一方面拥抱最佳实践，另一方面当员工离职的时候能够快速融入主流。
 |
1
GoLand 2020-07-01 10:22:55 +08:00
GitHub Flow https://guides.github.com/introduction/flow/ ，简单易理解，好实施。
|
 |
2
wangxiaoaer OP @GoLand #1 每人 fork 一个仓库吗？
|
|
3
GoLand 2020-07-01 10:39:17 +08:00  2
@wangxiaoaer 是的，每人 fork 一个仓库，各自仓库上建 branch，之后往主仓库提交 pull request，合并到主仓库 master 后部署上线就行了。
|
 |
4
vx 2020-07-01 10:50:11 +08:00
|
|
5
wangxiaoaer OP @vx #4 多谢。
|
|
6
wangxiaoaer OP @GoLand #3 这样会不会导致仓库里面很多重名仓库（虽然在各自名下），explore 的时候很乱？
|
|
7
GoLand 2020-07-01 11:17:32 +08:00
@wangxiaoaer 别人 fork 到自己的名下了，你又不用管别人的仓库。
|
 |
8
yEhwG10ZJa83067x 2020-07-01 11:33:06 +08:00
|
 |
9
lewinlan 2020-07-01 11:44:56 +08:00 via Android 1
小团队还用 fork ？迷
|
|
10
wangxiaoaer OP @lewinlan #9 不然呢？
|
 |
11
caviar 2020-07-01 12:06:47 +08:00 via iPhone
没必要 fork，每个人都在自己的名字下开 branch 就行吧。例如 username/foobar 这类
|
 |
12
doublleft 2020-07-01 12:08:41 +08:00
@wangxiaoaer #10 开分支 然后 rebase 呗，一天 10 个迭代，日清 20 个 bug 常事，难道每次都要 fork->MR 么
|
 |
13
GeruzoniAnsasu 2020-07-01 12:58:59 +08:00 via Android
为什么往一个库里怼不好？ 又不是往一个分支怼
|
 |
14
undef404 2020-07-01 13:43:17 +08:00
github flow 里没说要 fork repo 啊?
|
|
15
wangxiaoaer OP @undef404 #14 是的，我刚开始下意识一位 PR 是跨库的，现在看来 PR 也可以在同一个库上面操作。
那现在的问题就是 在同一个库中，权限的控制了，比如 master 不能提交，有权限的人员可以接受、检查 pr 并合并到 master 分支，这个我需要去查一查 |
 |
16
weixiangzhe 2020-07-01 13:51:56 +08:00 via Android
gitlab flow 吧 简单点
|
|
17
weixiangzhe 2020-07-01 13:53:23 +08:00 via Android
git flow 好多东西用不上，release 分支啥的基本用不到， 结我们现在是 gitlab flow 加点 feature 和 hotfix 分支
|
 |
18
aabbcc112233 2020-07-01 14:01:10 +08:00
小团队整那么复杂干啥
|
|
19
wangxiaoaer OP 1
@aabbcc112233 #18 希望组员得到锻炼，防止他们跟时代脱节，否则离职找工作的时候发现别人都机械化了，自己还是拿个镰刀挥舞，无所适从。
|
|
20
aabbcc112233 2020-07-01 14:33:12 +08:00
@wangxiaoaer 小公司要的就是机动性，没必要用大公司那一套。在什么位置就要做什么样的事，照搬可能带来恶果。当然我不是在否定大公司的做法，是要有选择性的使用。
|
 |
21
cedoo22 2020-07-01 14:37:25 +08:00
@wangxiaoaer 新来的公司还在用 svn 。。。。8 、9 个人的团队，SVN 都当文件共享服务器在用。。
|
 |
22
adajoy 2020-07-01 15:13:23 +08:00
@GoLand github flow 上是先部署，生产上验证没问题以后再合 master 。这样就有问题吧？ 1. 部署和合并间隔过久？ 2.多个 feature 如何处理？
|
|
23
GoLand 2020-07-01 15:17:29 +08:00
@adajoy 可以调整啊。branch 可以部署 staging 之类的环境，验证没问题再合进 master，一般合进 master 之后才上 prod
|
 |
24
Mithril 2020-07-01 15:19:35 +08:00
可以参考 Git Flow 。
本质上就是保护主线，确保每次在主线上的提交都是通过 PR 进来的，Review 和 CI 过的。 至于你 PR 是跨库提进来的，还是跨分支进来的都无所谓。 实际上根据团队情况灵活应对就行了。 缺点就是提 PR 的人需要根据情况不停解决 Merge Conflict 。但是这个问题是没法避免的，SVN 还是 Mercurial 还是什么其他的 flow 都没办法解决。只要多人开发就总会有冲突需要解决的。 |
 |
25
wulin 2020-07-01 16:32:04 +08:00 1
一开始试验过每个人 fork 后再建分支，实践过程中发现太麻烦了
改成在主仓库建不同分支，master 只接受合并不可提交 所有冲突全部拒绝，个人本地 pull 最新代码处理好了冲突再提交，比较适合几个人的小团队。 |
 |
26
sarices 2020-07-01 16:43:36 +08:00
小团队就不要 fork 了，没必要，浪费时间，锁定 master 分支就好
|
 |
27
tsaohai 2020-07-01 17:29:57 +08:00 via iPhone
master 的 policy 设置好，CI 配好，每个人自己开分支发 PR 就可以了。
|
 |
28
gesse 2020-07-01 20:51:13 +08:00
|
 |
29
frankkai 2020-07-01 21:31:30 +08:00
|
|
30
frankkai 2020-07-01 21:34:31 +08:00
功能起 feature 、发布起 release 、改 bug 起 hotfix
线上环境 master 、测试环境一个、拟生产环境一个 目前没遇到太大的问题 感觉还行 |
|
31
GeruzoniAnsasu 2020-07-01 21:56:37 +08:00
我们目前的实践（ 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 2020-07-01 22:57:13 +08:00 via Android
你可能是需要多开工程，而不是 fork pr 。小于 100 人的公司完全不需要 fork pr 流程。
|
 |
33
Erroad 2020-07-01 23:54:31 +08:00 via iPhone
一般的团队感觉没有多库的必要，而且这种东西每个公司都不太一样，去了现学一会儿也就上手，有啥脱节不脱节的
|
 |
34
ClericPy 2020-07-02 00:00:28 +08:00
以前一直走的老的 git flow, 就是单独项目开仓库, 功能分支自己 rebase 最后提 pr 然后等 review 再合并后面自动走 CI
然后去年突然看到楼主说的这种, 而且还好多文章 diss 我用过的那种, 到处充斥着 "时代变了" 的气息... 那些文章说的其实也是很有道理, 也是所有项目都在一个仓库, 然后开分支, 好处很明显是真的, 一次 make 全家受益 老了唉 |
 |
35
hhyvs111 2020-07-02 07:13:46 +08:00 via iPhone
开分支就好了，master 只合入
|
 |
36
gbin 2020-07-02 19:39:15 +08:00 via Android
#3 说得对，可以参考 Angular 的开发 flow
|
Select Language