Git教程(9)集中式工作方式常用的设计分支的方案
Git是一个复杂的版本管理系统,管理代码有很多工作方式,如集中式,管理者式,司令/副官式
本文是假设选用集中式工作方式时,设计分支的方案。
中小型项目:
维护两个长期分支,分别是master
和 develop
,master
分支只会在一个非常稳定的版本发布时才会更新,而所有的新代码会首先整合进入 develop
分支。
经过一段时间,确认develop稳定之后,将其以快进的形式并入 master 分支。在开发时各分支如下3图:
合并特性分支前:
合并特性分支后:
一次发布之后:
大型项目:
Git 项目包含四个长期分支:master
、next
,用于新工作的 pu
(proposed updates)和用于维护性向后移植工作(maintenance backports)的 maint
分支。 开发者先在pu中工作, 之后对pu进行测试评估,检查其是否已经能够合并,或者仍需要更多工作。 安全的pu会被合并入 next
分支,最后next会合并到master。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· 分享一个免费、快速、无限量使用的满血 DeepSeek R1 模型,支持深度思考和联网搜索!
· 基于 Docker 搭建 FRP 内网穿透开源项目(很简单哒)
· ollama系列1:轻松3步本地部署deepseek,普通电脑可用
· 按钮权限的设计及实现
· 【杂谈】分布式事务——高大上的无用知识?