前两篇介绍了 git基本概念 和 具体的规范,本篇针对不同的使用场景做演示。
分支
分支命名
- master 分支名称保持不变
- develop 分支名称保持不变
- feature/<分支名称> 功能分支
- release/<分支名称> 待上线分支
- hotfix/<分支名称> 线上紧急修复分支
拉取远程分支
git checkout -b <分支名称> origin/<分支名称> 拉取并关联远程分支
创建新分支
git checkout -b <分支名称> 创建新分支并切换到新分支
<!-- more -->提交备注规范
首行,简明扼要地描述更新内容;
空出一行;
之后,详细描述更新内容。
如果对应jira的问题,填写jira路径:issue:http://jira.n.xiaomi.com/test1
举例
修复bug,工单详情页面,工单记录页面,客服头像不显示
<空行占位符>
导致原因:代码逻辑考虑不全
jira: http://jira.n.xiaomi.com/test1
如何整理自己的commit,保持commit清晰
git commit —amend 修改最近一次提交;
git rebase -i 整理提交
- edit,编辑某一次提交的备注;
- squash,把当前commit向前合并,一直合并到pick为止;
- fixup,和squash非常类似,唯一的区别就是,fixup会忽略当前commit的信息;
再次强调:如果commit已经提交到远程git仓库,一定不要再进行整理合并commit。
举例说明
-
基于develop分支创建一个功能分支,名称为feature/feature1;
git checkout -b feature/feature1
-
新建一个文件test.txt,提交;
git commit -m ‘add test.txt file’
-
修改文件test.txt,添加一行内容,提交;
git commit -m ‘update text.txt file, append content: love vae music’
-
发现上一步添加的内容错误,想修改内容,但不添加新的commit
修改为正确的内容;git commit —amend; 会弹出修改窗口,修改注释,如果不变,直接回车;
-
连续提交3个commit,但想合并为1个commit;
-
使用git log,确定要rebase的commit-id;
-
git rebase -i df87607d5dd24c0a73f23284e6988d6d32c0d3a4 显示编辑窗口
-
进行编辑,修改如下:
-
最终结果只会保留commit1:
新人加入,如何加入开发
从远程拉取develop分支:
git checkout -b <分支名称> origin/<分支名称> 拉取并关联远程分支
如果要开发新功能,基于develop分支创建feature分支:
git checkout -b feature/feature1
如果要修复线上紧急bug,基于master分支创建hotfix分支:
git checkout -b hotfix/hotfix1
开发一个feature
基于develop分支创建feature分支;
开发完成后,整理自己的commit,把无意义的commit进行合并;
准备在下一次迭代上线,整理完成后,合并到develop分支;
不准备在下一次迭代上线,整理完成后,push当前分支到远程git仓库,等待准备上线时,再合并到develop分支:
git push origin feature/feature1:feature/feature1
合并到develop分支前,一定要经过本地测试!
确定版本上线计划及上线
整体上,要有明确的上线计划,确定每次上线哪些功能;
只有确认在下一次版本上线的feature才能合并到develop分支;
提交测试,修复测试反馈的bug
提交测试前,确保所有人的代码修改都已提交到develop分支;
基于develop分支,创建release分支:
git checkout -b release/release1
发布release/release1分支到测试环境,测试人员进行测试;
测试过程中发现的bug,直接在release分支进行修复并提交;
测试完成,确认上线,合并代码到master分支和develop分支,用release分支名打Tag,删除release分支:
git tag release.1.1.1
git branch -d release/release1
修复线上bug
基于master分支,创建hotfix分支
git checkout -b hotfix/hotfix1
修复完成后,finish hotfix,合并代码到master和develop分支;
欢迎扫描下方二维码,关注我的个人微信公众号 ~
相关推荐
Git分支管理规范旨在为开发团队提供一个清晰、有序的工作流程,它将代码的不同阶段(如开发、测试、发布)与相应的分支关联起来,以促进协同工作和版本控制。通过规范化的分支策略,可以避免代码冲突,保证代码质量...
### git分支管理策略详解 #### 一、引言 在当今的软件开发环境中,版本控制系统是必不可少的一部分。其中,Git因其高效性和灵活性成为了最受欢迎的选择之一。对于任何希望提高团队协作效率、确保代码质量和版本可...
3. **分支与合并:** Git鼓励频繁地使用分支和合并操作。开发者可以在不同的分支上独立开发新功能或修复bug,然后通过合并将这些更改合并回主分支。这种工作流可以有效减少冲突,并提高团队协作的效率。 #### 三、...
1. **定期合并**:为了保持分支间的同步,开发分支和临时性分支应定期与Develop和Master分支合并,避免出现大的合并冲突。 2. **代码审查**:在合并前,建议进行代码审查,以保证代码质量,发现潜在问题。 3. **...
Git 代码管理规范对软件开发过程中的代码管理、分支管理、版本号管理、代码审查和项目管理等方面都进行了详细的规定和解释。遵循这些规范,可以确保项目的代码质量和可靠性,并提高项目的开发效率和质量。
Git 是一个分布式版本控制系统,广泛应用于软件开发中的代码管理和协作。在企业环境中,Git 分支策略是确保项目高效、稳定推进的关键。以下是对"git分支版本管理.pdf"中提到的知识点的详细说明: 1. **主分支...
Git的分支特性使得这种管理变得可能,通过合理规划分支,可以实现需求开发、bug修复和版本发布等工作的并行处理。 ### 3. 定义 - **Master主干**:代表项目的正式发布版本,所有上线的代码均来自此分支。 - **...
通过遵循GitFlow分支模型并优化现有工作流程,可以显著提高团队协作效率,减少错误和冲突,确保项目代码的稳定性和可维护性。同时,良好的版本管理和分支策略也有助于团队成员更好地理解项目的进展和各自的责任。
Git 分支规范可以分为五种:master 分支、develop 分支、feature 分支、release 分支和 hotfix 分支。 master 分支 master 分支是主分支,也是用于部署生产环境的分支,确保 master 分支稳定性。master 分支一般由...
GIT分支管理 远程分支 本地分支 GIT分支管理 远程分支 本地分支
"Git源代码管理规范" 一、分支管理 ...Git 源代码管理规范包括分支管理、工作原理、常用命令和操作流程四个方面。只有遵循这些规范,我们才能更好地管理我们的源代码,提高我们的开发效率和产品质量。
内容概要:文档详细介绍了针对公司内部项目的 Git 分支管理和版本发布规范,涵盖版本分类及其驱动源,分支分类及命名规则,不同情况下代码分支的合并及发布流程,强调了分支间的流转规则与发版前后的注意事项。...
Gitflow工作流没有用超出功能分支工作流的概念和命令,而是为不同的分支分配一个很明确的角色,并定义分支之间如何和什么时候进行交互。除了使用功能分支,在做准备、维护和记录发布也使用各自的分支。当然你可以用...
1. 分支:`git branch`创建和管理分支,`git checkout`切换分支,`git merge`合并分支。 2. 仓库同步:`git remote`管理远程仓库,`git fetch`获取远程更新,`git pull`拉取并合并远程更新,`git push`推送本地更改...
这种工作流强调的是同步和更新,而不是分支管理。 **Gitflow工作流**是一种更为结构化的方法,适用于大型项目和需要多个版本并行开发的团队。Gitflow引入了两个长期分支:`master`(用于发布)和`develop`(用于...
Git工作流是指使用Git进行软件开发时采用的一系列流程和规范,这些流程和规范有助于团队协作、代码管理以及提高开发效率。 首先,Git与传统的版本控制系统如Subversion、Perforce有着本质的不同。传统的版本控制...
Git flow是一种常见的Git工作流模式,它定义了明确的分支策略,包括开发分支、特性分支、发布分支和热修复分支,以规范团队协作流程。 本书可能涵盖了以下关键知识点: 1. **Git基础**:安装与配置Git,创建和克隆...
Git 分支管理和团队协作规范是高效软件开发的关键组成部分。Git 是一种分布式版本控制系统,它允许开发者在多个分支上同时工作,有效地支持了敏捷开发和持续集成。以下是对标题和描述中提到的知识点的详细说明: 1....