Git 三大分支策略， 2 个人的前端团队，开发一个中型应用，适合用哪种策略
unt · 2022-07-13 22:01:45 +08:00 via iPhone · 3346 次点击这是一个创建于 866 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在哪种策略比较主流，易于操作
 |
1
zhlxsh 2022-07-13 22:17:23 +08:00 via iPhone
那三大？
|
 |
2
1217950746 2022-07-13 22:19:04 +08:00  1
|
 |
3
unt OP @1217950746 先赞为敬
|
|
5
1217950746 2022-07-13 22:23:58 +08:00
@unt 这个分支结构更加简单和灵活，我之前用 gitflow 比较多，后来就换这种简单结构了（不全用）
|
|
6
1217950746 2022-07-13 22:25:37 +08:00
@unt 更多的时候，我会选择 Rebase 干掉 Merge xxxx 之类的记录
|
 |
7
AngryPanda 2022-07-14 01:05:53 +08:00 via iPhone
人少的话，我投 gitlab flow 一票
|
 |
8
Vaspike 2022-07-14 08:53:06 +08:00
请问各自 fork 一个主仓库然后各自向主仓库 pull request(merge request)的方式有啥名字不
|
 |
9
guchengzhihuan 2022-07-14 09:07:41 +08:00 2
一人一个开发分支，做好了往主分支合并就完了
|
 |
11
caixiangyu17 2022-07-14 09:32:11 +08:00
trunk based development
|
 |
12
unco020511 2022-07-14 09:59:58 +08:00
很简单,一个主分支,n 个 feature 分支,通过 mr(pr)往主干合
|
 |
13
jones2000 2022-07-14 10:13:02 +08:00 1
就 2 个人还要什么策略，各管各开发。2 个人负责独立的模块，不要有耦合，交互定义好接口协议或接口函数就行了。后期联调就完事了。
|
 |
14
leiuu 2022-07-14 10:35:18 +08:00 1
这种 case 简单的主干开发模式可能比较适合 这三个都不用
|
 |
15
janus77 2022-07-14 11:14:50 +08:00 1
2 个人不是 master 一把梭？还有策略？
|
 |
16
justicelove 2022-07-14 11:24:25 +08:00
赞楼上
|
|
17
unt OP |
|
18
unt OP 谢谢，全赞了一遍
|
 |
19
zhuweiyou 2022-07-14 13:07:22 +08:00
直接主分支开发
|
 |
20
seth19960929 2022-07-14 13:32:44 +08:00
上面的人都是疯了吗, 直接 master 开发, 这要是代码还在测试有 bug 继续修复怎么上.
我个人认为比较实用的 master => prod dev => 测试 A, B 开发者(对于你们两个人) 开发新功能就从 master checkout 一个 feature 分支. 然后开发完成推到线上, 合并到 dev 分支, 然后部署到测试环境. 测试通过验收后, feature 分支合并到 master 分支, 部署线上 |
|
21
jones2000 2022-07-14 14:11:10 +08:00
@unt 2 个人垒界面就够累的了，更不要提核心模块的研发了， 没有核心技术就靠开源堆出来的东西，没有门槛，也没有竞争力，路走不长的。
|
|
23
unt OP 😩 😩 说错了说错了，4 个人的团队
|
 |
24
qwerthhusn 2022-07-14 14:23:06 +08:00
一两个人，就 master 一条路走到黑
|
 |
25
AyaseEri 2022-07-14 15:11:45 +08:00
dev 一条，qa 一条，master 一条。
一路 rebase 走到底。 |
 |
26
karott7 2022-07-14 15:14:04 +08:00
说一条 master 分支走到黑的也太狠了吧，个人觉得一个长期项目即使是一个人开发也最好遵循某一个分支开发流程
|
 |
27
laolaowang 2022-07-14 16:12:55 +08:00
我司 是 master / feature-*** 足矣
|
 |
28
mazai 2022-07-14 16:59:40 +08:00
我司是主仓库 master （ pord ），dev （ test ，uat ）两个分支
每个开发 fork 主仓库到自己的仓库，在自己的仓库开发，push 之后，提交 PR 到主仓库，给领导 CR ，没问题就合并到主仓库的 dev 分支。 功能 dev 完毕没问题，就合并到主仓库的 master 分支，发布环境。 |
 |
29
fpure 2022-07-14 17:27:55 +08:00
直接一个主分支，小改动就直接在上面改，大改动就建个新分支改完合并
|
 |
31
u823tg 2022-07-14 22:31:27 +08:00
@unt #30 楼上说的也没多大错， 两个人太复杂的策略目测是坚持不下来的。 太复杂也会降低你们开发效率， 一个人在 n 个 feature n 个 fix dev master 切换。 人少精简点别自己给自己找麻烦。 人多了可以上那些开发策略
|
 |
32
imycc 2022-07-14 22:33:33 +08:00
以前用的 gitflow ，实践中开始往 gitlab flow 靠，我觉得还行。
用 gitflow 最麻烦的问题是长生命周期的分支，在合并的时候会引入大量的差异，做 Code Review 很累人。尽量细化功能分支、多提交，多跟进主分支，能一定程度缓解问题。 同时去看了一些人在推荐的 trunk based development ，理念也不错，但要求不低。团队人力充足、有专职测试、发布频繁的，可以试试。 |
 |
33
GiantHard 2022-07-14 22:47:39 +08:00
投 trunk based development 一票，记得完善自动化测试
|
 |
34
msg7086 2022-07-15 02:14:35 +08:00
trunk based development 这个比较适合传统开发模式。
敏捷开发一般保证 dev/master 是随时可用，feature 上做功能。 传统开发一般保证 release/*是随时可用，dev/master 上做功能。（当然还是要配合 personal branch+MR 。） |
Select Language