Git主干分支master开发优缺点

优缺点

主干开发:是指开发人员直接向主干(习惯上主干分支通常为:main或master)提交/推送代码。通常开发团队的成员1天至少一次地将代码提交到主干分支,在到达发布条件时,从主干拉出发布分支通常为(release),用于发布,若发现缺陷,直接在主干上修复,并根据需要cherry pick到对应版本的发布分支,

优点缺点
分支模型简单高效,开发人员易于掌握不容易出现错误操作,基础架构要求高:合入到主干的代码若质量不过关将直接阻塞整个团队的开发工作,因此需要高效的持续集成平台进行把关;
避免了分支合并,冲突解决的困扰,自动化测试要求高:需有完备单元测试代码,确保在代码合入主干前能在获得快速和可靠的质量反馈,
随时拥有可发布的版本,有利于持续集成和持续交付最好有代码评审:若代码质量要求高,需要配套代码评审(CR)机制,在代码提交到主干时,触发CR,通过Peer Review后才能正式合入,
最好有特性开关:主干开发频发合入主干的情况下,特性拆分的很小,可能是半成品特性,需要配套开关(Feature Toggle),只有当特性整体开发完才通过灰度发布等手段逐步打开

场景

现代Git实践更倾向于使用main作为默认分支名称以避免某些文化上的敏感性问题)开发适合以下几种场景:

‌小型项目‌:对于规模较小、开发周期短、团队成员少的项目,使用主干分支开发可以简化流程,提高开发效率。

‌快速迭代‌:在需要快速迭代和频繁发布的情况下,主干分支开发能够减少分支管理带来的开销,使得新功能能够更快地集成到产品中。

‌持续集成/持续部署(CI/CD)‌:主干分支开发非常适合与CI/CD流程结合使用。通过自动化测试和部署,可以确保主干上的代码始终是可用的,从而加速开发到部署的整个过程。

‌功能分支较少‌:如果项目中大部分工作都是直接在主干上进行,且功能分支较少,那么使用主干分支开发是合理的。这种情况下,团队成员可以更容易地保持对项目的整体了解,减少合并冲突的可能性。

‌高度协同的团队‌:对于高度协同、沟通顺畅的团队来说,主干分支开发可以促进团队成员之间的紧密合作。通过频繁的代码审查和交流,可以及时发现和解决问题,确保项目的顺利进行。

然而,需要注意的是,主干分支开发也要求团队成员具备较高的责任感和自律性,以确保代码的质量和稳定性。同时,对于大型项目或需要长期维护的项目来说,可能需要更复杂的分支管理策略来应对不同的开发需求和版本控制问题。因此,在选择是否使用主干分支开发时,需要根据项目的实际情况和团队的特点进行权衡。

`git rebase` 和 `git merge` 都是 Git 中用于合并分支的操作,但它们的工作方式和影响略有不同: 1. **git rebase**: - **原理**: `git rebase` 将一个分支(通常是你的工作分支)的提交历史移动到另一个分支(通常是最新的主分支,如 `master` 或 `main`)之上,这样整个分支的历史看起来像是连续的。它会应用目标分支的每个提交到你的分支上,然后记录一个新的提交。 - **优点**: 可能导致更干净的提交历史,因为提交顺序更加线性,便于阅读和追踪更改。同时,如果在 rebase 过程中发现错误,可以很容易地进行编辑或交互式处理。 - **缺点**: 如果目标分支在你 rebase 期间有其他人的提交,可能会导致你的分支主干产生冲突,需要解决。此外,如果在公共仓库中使用不当,可能会导致历史混乱。 2. **git merge**: - **原理**: `git merge` 合并两个分支的内容,创建一个新的提交,该提交包含合并点之后两分支的所有更改。这个操作不会改变原有分支的提交历史,而是添加一个新的提交到合并点之后。 - **优点**: 更安全,因为合并操作不会改变已有分支的历史,不会对其他开发者造成困扰。更适合用于合并已经稳定的代码更改。 - **缺点**: 提交历史不连续,可能导致分支分支图显得混乱。如果有大量的合并,历史审查可能会变得困难。 **相关问题--:** 1. 在什么情况下你会选择使用 `git rebase`? 2. 在哪些情况下你更倾向于使用 `git merge`? 3. 如果我想保留原始提交顺序并避免冲突,应该使用哪种方法?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值