概述

在现代软件开发中，Git 已成为不可或缺的版本控制工具。然而，随着项目规模的增长和团队协作的深入，开发者常常面临提交记录混乱、分支管理无序以及冲突处理低效等问题。本篇文章将从提交历史优化、分支管理、冲突解决、git hooks在CI/CD中的应用等几个方面，结合实际场景，分享一系列实用的 Git 最佳实践与技巧。同时，还将介绍如何利用 IDEA 集成的 Git 工具高效完成常见任务，帮助大家在提升开发效率的同时，让代码管理更加清晰规范。

提交历史优化

清晰、整洁的提交历史是高效代码协作和维护的基石。一个明确的提交历史不仅能清晰描述代码的变更内容，还能帮助团队快速理解功能迭代的过程，便于问题追踪和代码审查。在实际开发中，合理利用 Git 提供的工具，例如 git rebase、git amend 和 git squash，可以优化提交历史，移除多余的提交，合并相关变更，甚至修正已有的提交信息，从而让提交历史更具可读性和逻辑性。这种优化不仅能提升团队协作的效率，还能在代码审查和版本管理中带来巨大的便利。

撰写清晰的提交信息

模糊的提交信息无法清楚描述改动内容，日后追溯时很难理解具体变更。

正面示例：

feat: 新增用户注册功能- 增加了用户注册表单验证逻辑- 使用邮件发送了注册确认链接- 优化了表单输入的错误提示

反面示例：

fix: 改了一些东西update: 更新了代码

分割和合并提交

将多个功能混在一起的提交，难以进行代码回溯和版本管理，后期维护成本高。

正面示例：每个提交只完成一个独立的功能或修复，避免 “杂糅提交”。

feat: 实现用户登录功能fix: 修复登录页面的样式问题test: 添加登录功能的单元测试

反面示例：

feat: 完成了用户注册和部分登录功能，还有一些小问题

Git 提交历史重写技巧

在开发过程中，提交历史可能会因为小错误、冗余提交或逻辑混乱而变得凌乱。通过 Git 提供的历史重写工具，如 git amend 和 git squash，可以对提交记录进行细致的调整，让提交历史更加清晰、合理。

git commit --amend：修改最近一次提交

git amend 用于修改最近一次提交，无需新增一个提交记录。它可以用来修正提交信息、补充漏掉的文件，或者调整提交内容。

常见场景及用法：

修正提交信息
如果最近一次提交的描述有误，可以使用以下命令重新编辑提交信息：

git commit --amend

Git 会打开默认的编辑器，允许修改提交说明。保存后，原提交记录将被替换为新的提交。

补充漏提交的文件
假如在提交后发现漏掉了某些文件：

git add <missed-file>git commit --amend

这样，新增的文件会被追加到最近一次提交中，提交历史保持整洁。

注意事项：使用 --amend 会重写提交历史，不要对已经推送到远程的提交执行此操作，避免影响他人代码。对于自己的分支，需要使用git push -f 强行覆盖已经push到远端的提交。

git rebase -i：使用 git squash 合并提交

git squash 是在交互式 rebase (git rebase -i) 中用于合并多个相关提交的命令。通过合并零散的提交，可以让提交历史更具逻辑性和条理性。

常见场景及用法：

开始交互式 Rebase
假设你想合并最近的 3 次提交：

git rebase -i HEAD~3

此时会打开一个交互式编辑器，显示如下内容：

pick abc123 First commitpick def456 Second commitpick ghi789 Third commit

指定合并方式
将后续需要合并的提交改为 squash 或 s：

pick abc123 First commitsquash def456 Second commitsquash ghi789 Third commit

编辑合并后的提交信息
保存后，Git 会提示编辑合并后的提交信息：

# This is a combination of 3 commits.# The first commit message:First commit# The following commit messages:Second commitThird commit

你可以选择保留、合并或重写提交信息。编辑完成后保存退出，Git 将自动合并提交，最终的提交历史将更加简洁。

IDEA中的提交历史修改

IDEA中提交当前代码的快捷键是Ctrl + K 我们在提交信息栏中可以找到amend选项，对应了git amend操作，把当前提交合并入上次提交。
![][image1]

另外，在集成的git工具中，我们右键选中的提交，可以选择编辑提交信息与squash操作。
![][image2]

分支管理

分支命名与使用规范

正面示例：使用统一的命名规范，根据功能或类型划分，使用 develop、feature、release、hotfix 等规范分支

feature/add-user-loginbugfix/fix-login-errorhotfix/security-patch

反面示例：随意创建分支，缺乏明确的管理策略

branch123myfixtemp

合并分支

在团队协作中，本地分支需要定期与远程分支同步，以确保代码最新。传统方式是通过 git merge 合入远程分支的变更，但这通常会产生冗余的合并提交，导致提交历史杂乱。通过 git rebase，可以将远程分支的更新“平滑地”合并到本地分支，提交历史更显整洁。

git merge (合并分支)

将两个分支的最新提交整合，生成一个新的合并提交（merge commit）。不修改已有提交历史，保留所有原始提交。
示例：

A---B---C (main) \ D---E (feature)

使用 git merge 后：

A---B---C---M (main) \ / D---E (feature)

其中 M 是新的合并提交。

git rebase (变基)

将 feature 分支的更改移至 main 的最新提交之上，相当于重新应用一遍。
修改提交历史，使其看起来更线性、更整洁。
示例：

A---B---C (main) \ D---E (feature)

使用 git rebase 后：

A---B---C---D'---E' (feature rebased onto main)

git rebase 的好处

保持提交历史线性、简洁。git rebase 使提交历史看起来像一个单独的分支线，避免了额外的合并提交。适合需要清晰、连续历史记录的场景，如开源项目或长期维护的项目。
示例对比：
使用 git merge：

| * Merge branch 'feature' into 'main'|\| * Feature Commit E| * Feature Commit D* | Main Commit C|/* Main Commit B |
| :---- |

使用 git rebase:

* Feature Commit E* Feature Commit D* Main Commit C* Main Commit B

• 避免不必要的合并提交
  每次 git merge 都会生成一个合并提交，如果频繁操作，提交历史会显得冗余和凌乱。git rebase 则直接将变更应用到主分支，避免合并提交的累积。

• 更容易阅读与回溯
  团队或个人在回溯历史时，可以更直观地理解每个提交的变化和原因。git rebase 生成的历史记录更清晰，无需额外理解复杂的分支结构。

• 提升代码质量（中间冲突修复）
  git rebase 过程中可以逐个修复冲突，确保每个提交都是完整且正确的。避免在合并时出现大规模冲突，一次解决多个问题带来的风险。

什么时候选择 git rebase？

个人开发分支的整合：当你在一个独立分支上完成开发，并希望提交历史清晰时，git rebase 是最佳选择。
小团队协作或线性开发：适用于保持代码库整洁、简洁的场景。

什么时候选择 git merge？

大型团队协作：当多人在同一分支上工作时，git merge 保留了完整的开发历史，可以追溯并发工作。
保留真实历史：当你希望完整记录合并的每个分支历史时，git merge 更合适。

合并冲突之git rerere

git rerere 的使用场景

1. 反复 Rebase 或 Merge
   当在长时间存在的功能分支上开发时，频繁从主分支合并更新可能会遇到相同的冲突。启用 git rerere 后，Git 会自动应用之前的冲突解决，避免重复劳动。
2. 团队协作中的复杂冲突
   在多人合作时，如果不同开发者在多个地方解决了相同冲突，团队可以共享冲突解决记录，统一冲突处理方式。

git rerere 的工作原理

1. 记录冲突解决方式：当你解决了一次冲突并提交后，git rerere 会自动记录该冲突的解决方式。
2. 自动复用解决方案：下一次遇到相同冲突时，Git 会自动应用之前的解决方案，减少手动解决冲突的步骤

如何启用 git rerere

全局启用：

git config --global rerere.enabled true

针对单个仓库启用：

git config rerere.enabled true

实际操作流程

处理初次冲突
遇到冲突时，解决冲突并标记为已解决：

git add <resolved-file>git commit

复用解决方案
当再次遇到相同冲突时，Git 会自动应用之前的解决方案，并标记文件为已解决。如果需要验证：

git status

1. 可以看到冲突已被自动解决。
2. **手动确认或调整：**如果自动解决不完全正确，可以手动编辑文件，然后重复 git add 和 git commit。

git rerere 的优缺点

优点：

• 减少重复冲突解决的时间，特别适合长时间开发的功能分支。
• 提高复杂项目的冲突解决效率。

缺点：

• 需要团队成员统一使用，且冲突记录可能需要共享才能充分发挥作用。
• 在解决方式不完全匹配时，仍需手动调整。

IDEA中的pull代码

IDEA中pull远程代码的快捷键是Ctrl + T我们在拉代码过程中可以选择rebase或者merge远程代码到本地。
![][image3]

git patch 与 git apply

在代码协作与提交历史优化中，git patch 和 git apply 是一对强大的工具组合。git patch 用于生成变更补丁文件，而 git apply 则可以将这些补丁应用到工作目录中。它们可以帮助开发者在跨分支、跨仓库传递变更，或在代码回滚、细化提交时精确控制变更内容。

git patch 生成补丁

Git 可以生成包含代码修改内容的补丁文件，供其他人应用到自己的代码库中。

生成补丁文件的常见方法

使用 git diff 生成基础补丁

git diff > changes.patch

• 此命令生成工作区未提交的更改的补丁文件。
• changes.patch 是一个包含代码差异的文本文件，记录了具体的新增、删除或修改。

git apply 应用补丁

git apply 用于将补丁文件中的修改应用到当前代码库，但不会自动生成提交记录。

基本用法

git apply changes.patch

此命令将 changes.patch 中的修改应用到当前工作区。

查看补丁应用的效果 在实际应用补丁前，可以通过 --check 检查补丁是否能成功应用：

git apply --check changes.patch

将补丁文件应用为提交

如果希望直接将补丁文件作为一次提交，可以使用 git am 命令（适用于由 git format-patch 生成的补丁文件）：

git am changes.patch

IDEA中的patch与apply操作

IDEA中可以使用集成的git工具生成和应用patch文件，具体位置如截图所示。
![][image4]![][image5]

git hooks

在团队协作开发中，开发者可能会因为疏忽忘记在本地运行测试，直接将代码提交到远程仓库，导致在 CI/CD 流程中测试失败，浪费时间。通过 Git Hooks，我们可以在本地 push 或 commit 代码时，自动执行测试命令，如运行 Maven 的单元测试，确保代码的质量和稳定性。

Git Hooks 简介

Git Hooks 是 Git 提供的脚本功能，可在特定的 Git 操作（如 commit、push）之前或之后触发自定义逻辑。例如：

• pre-commit：在 git commit 命令之前执行。
• pre-push：在 git push 命令之前执行。

在 push 时运行 Maven 单元测试

在团队协作开发中，开发者可能会因为疏忽忘记在本地运行测试，直接将代码提交到远程仓库，导致在 CI/CD 流程中测试失败，浪费时间。通过 Git Hooks，我们可以在本地 push 或 commit 代码时，自动执行测试命令，如运行 Maven 的单元测试，确保代码的质量和稳定性。

我们可以使用 pre-push Hook 在推送前执行单元测试。以下是具体实现步骤：

创建 pre-push Hook 文件

进入项目的 Git 配置目录：

cd .git/hooks

创建并编辑 pre-push 文件：

touch pre-pushchmod +x pre-push # 确保 Hook 文件具有可执行权限

在 pre-push 文件中添加以下脚本：

#!/bin/bashecho "Running Maven tests before pushing..."# 运行 Maven 单元测试mvn testif [ $? -ne 0 ]; then echo "Unit tests failed. Push aborted." exit 1fiecho "All tests passed. Proceeding with push."exit 0

测试 Hook 是否生效

1. 在代码中故意引入一个可能导致单元测试失败的错误。
2. 尝试执行 git push：
   • 如果测试失败，pre-push Hook 会中止推送，并提示错误原因。
   • 如果测试成功，代码会正常推送到远程仓库。

总结

Git 的强大不仅体现在版本控制的基础能力上，更在于其灵活的操作方式和丰富的工具支持。通过优化提交历史、规范分支管理以及高效处理冲突，开发者可以更有条理地管理代码版本，提升协作效率，降低开发过程中的复杂性。希望本文的实践分享能够为您和您的团队提供有价值的参考，助力构建一套高效、规范的 Clean Git 工作流。