Git 分支管理与提交规范_java git代码提交规范以及示例-优快云博客

本文链接：https://blog.youkuaiyun.com/adaivskean/article/details/124878194

本文介绍了Git分支管理策略，重点讲解了git-flow及其包含的master、develop、feature、release和hotfix五类分支的使用场景和生命周期。同时，文章详细阐述了代码提交规范，包括代码提交流程和Commit message的格式，强调了提交信息的结构化要求。此外，文中还提及了代码库的换行设置和冲突解决等操作要点。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Git 分支管理与提交规范

背景

Git 是目前最流行的源代码管理工具。大量的软件项目由 GitHub、GitLab 这样的云服务平台或是私有的 Git 仓库来管理。在使用 Git 时通常会遇到的一个问题是采用何种分支管理实践，即如何管理仓库中作用不同的各类分支。和软件开发中的其他实践一样，Git 分支管理并没有普遍适用的最佳做法，而只有对每个团队和项目而言最适合的做法。简单来说，在项目开发中使用多个分支会带来额外的管理和维护开销，但是多个分支对于项目的团队合作、新功能开发和发布管理都是有一定好处的。

一. 分支管理策略

git-flow 应该是目前流传最广的 Git 分支管理实践。git-flow 围绕的核心概念是版本发布（release）。因此 git-flow 适用于有较长版本发布周期的项目。虽然目前推崇的做法是持续集成和随时发布。有的项目甚至可以一天发布很多次。随时发布对于 SaaS 服务类的项目来说是很适合的。不过仍然有很大数量的项目的发布周期是几个星期甚至几个月。较长的发布周期可能是由于非技术相关的因素造成的，比如人员限制、管理层决策和市场营销策略等。
git-flow 流程中包含 5 类分支，分别是 master、develop、新功能分支（feature）、发布分支（release）和 hotfix。这些分支的作用和生命周期各不相同。master 分支中包含的是可以部署到生产环境中的代码。develop 分支中包含的是下个版本需要发布的内容。从某种意义上来说，develop 是一个进行代码集成的分支。当 develop 分支集成了足够的新功能和 bug 修复代码之后，通过一个发布流程来完成新版本的发布。发布完成之后，develop 分支的代码会被合并到 master 分支中。

其余三类分支的描述如下所示。这三类分支只在需要时从 develop 或 master 分支创建。在完成之后合并到 develop 或 master 分支。合并完成之后该分支被删除。这几类分支的名称应该遵循一定的命名规范，以方便开发人员识别。

分支类型	命名规范	创建自	合并到	说明
feature	feature/*	develop	develop	新功能
release	release/*	develop	develop 和 master	一次新版本的发布
hotfix	hotfix/*	master	develop 和 master	生产环境中发现的紧急 bug 的修复

对于开发过程中的不同任务，需要在对应的分支上进行工作并正确地进行合并。每个任务开始前需要按照指定的步骤完成分支的创建。例如当需要开发一个新的功能时，基本的流程如下：
a. 从 develop 分支创建一个新的 feature 分支，分支命名规则：feature/缺陷号，如 feature/ibreeze-001。
b. 在该 feature 分支上进行开发，提交代码，push 到远端仓库。
c. 当代码完成之后，合并到 develop 分支并删除当前 feature 分支。
在进行版本发布和 hotfix 时也有类似的流程。当需要发布新版本时，采用的是如下的流程：
a. 从 develop 分支创建一个新的 release 分支，如 release/1.4。
b. 把 release 分支部署到持续集成服务器上进行测试。测试包括自动化集成测试和手动的用户接受测试。
c. 对于测试中发现的问题，直接在 release 分支上提交修改。完成修改之后再次部署和测试。
d. 当 release 分支中的代码通过测试之后，把 release 分支合并到 develop 和 master 分支，并在 master 分支上添加相应的 tag。

二、代码提交规范

代码提交过程命令示例如下，也可使用开发工具提交，只要符合规范即可。

git pull origin develop:develop // 必须
git checkout -b feature/ibreeze-001 // 必须 ,其中ibreeze-001改为缺陷号。
开发代码
git status //建议，通过IDE可视化操作时注意查看自己修改的内容
git add -A // 必须参数可选(.英文句号，提交新增和修改;-A 提交所有变化;-u 提交修改和删除，不包括新建)，可以指定文件名
git status //建议，通过IDE可视化操作时注意查看自己修改的内容
git commit -m ‘【功能模块】变更描述’ //必须
git pull origin develop // 必须
如无冲突则继续下一步，有冲突则解决冲突
git push -u origin feature/ibreeze-001 //必须
自测完成后在Gitlab发起合并请求，源分支为feature/ibreeze-001，目标分支为develop,正确合并完成后删除来源分支，已合并的分支需要再次修改则建立新分支。

注意事项：

git config core.autocrlf input
设置自动换行转义，Windows设置为true，linux、Mac设置为input。参考Git换行问题
git config core.safecrlf true
强制校验换行符号与仓库一致
git checkout feature/ibreeze-001
当目标分支修改提交后可不加选项切换到其他分支，-b 选项为创建并切换分支
git branch -a 可查看所有本地分支，-d 删除指定分支

用代码库文件覆盖本地文件

git fetch --all
git reset --hard origin/develop

三、Commit message 的格式

效果参考

在这里插入图片描述
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中，Header 是必需的，Body 和 Footer 可以省略。

不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。

3.1 Header

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

（1）type

type用于说明 commit 的类别，只允许使用下面7个标识。

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动

如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

（2）scope

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

（3）subject

subject是 commit 目的的简短描述，不超过50个字符。

以动词开头，使用第一人称现在时，比如change，而不是changed或changes
第一个字母小写
结尾不加句号（.）

3.2 Body

Body 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。

More detailed explanatory text, if necessary.  Wrap it to 
about 72 characters or so. 

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Use a hanging indent

有两个注意点。

（1）使用第一人称现在时，比如使用change而不是changed或changes。

（2）应该说明代码变动的动机，以及与以前行为的对比。

3.3 Footer

Footer 部分只用于两种情况。

（1）不兼容变动

如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。

BREAKING CHANGE: isolate scope bindings definition has changed.

    To migrate the code follow the example below:

    Before:

    scope: {
      myAttr: 'attribute',
    }

    After:

    scope: {
      myAttr: '@',
    }

    The removed `inject` wasn't generaly useful for directives so there should be no code using it.

（2）关闭 Issue

如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。

Closes #234

也可以一次关闭多个 issue 。

Closes #123, #245, #992

3.4 Revert

还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。

revert: feat(pencil): add 'graphiteWidth' option

This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

Body部分的格式是固定的，必须写成This reverts commit <hash>.，其中的hash是被撤销 commit 的 SHA 标识符。

如果当前 commit 与被撤销的 commit，在同一个发布（release）里面，那么它们都不会出现在 Change log 里面。如果两者在不同的发布，那么当前 commit，会出现在 Change log 的Reverts小标题下面。

参考

阮一峰-Commit Message
git-chglog: example-type-scope-subject