Kotlin开发者的Git工作流：如何不搞砸项目

引言：为什么Git不仅仅是“git push”

如果你用Kotlin编程，你会知道这门语言是多么令人愉悦：简洁、安全、现代。但即使是最优雅的代码，如果团队没有清晰的Git工作流，也会变成一团乱麻。你是否曾尝试合并一个分支，其中一个开发者重命名了半数文件，另一个重构了协程，而第三个不小心提交了包含本地路径的`build.gradle.kts`？

Kotlin开发者的Git工作流不仅仅是枯燥的规则。它是你抵御冲突的盾牌、稳定`main`分支的保障，以及避免在周一花费时间排查“谁搞坏了什么”的方法。在本文中，我们将剖析一个真实的流水线：从为Kotlin配置`.gitignore`，到通过Gradle和pre-commit钩子进行自动检查。

让我们开始整理仓库吧！

1. 基础：为Kotlin配置仓库

1.1. 为Kotlin设置正确的.gitignore

每个人要做的第一件事就是忘记从GitHub复制粘贴模板。在Kotlin项目中，有一些特定的文件夹不应进入仓库。以下是最基本的必备配置：

# Kotlin & JVM\n*.class\n*.jar\n*.war\n*.ear\nbuild/\n!gradle/wrapper/gradle-wrapper.jar\n\n# IDE (IntelliJ IDEA)\n.idea/\n*.iml\n*.iws\nout/\n\n# OS\n.DS_Store\nThumbs.db\n\n# Gradle\n.gradle/\nlocal.properties\n

注意：我们明确排除了`.idea/`——这将避免同事在IDE配置上产生冲突。而`local.properties`（SDK路径）则完全是本地配置。

1.2. Git钩子：你的个人代码检查器

Kotlin开发者的Git工作流离不开pre-commit钩子。它们在提交创建之前运行。最流行的工具是pre-commit及其Kotlin插件。

`.pre-commit-config.yaml`配置示例：

repos:\n  - repo: https://github.com/pre-commit/mirrors-ktlint\n    rev: v0.50.0\n    hooks:\n      - id: ktlint\n        args: ["--format"]\n\n  - repo: https://github.com/detekt/detekt\n    rev: v1.23.1\n    hooks:\n      - id: detekt\n

现在，每次提交前，`ktlint`会格式化代码，`detekt`会检查潜在的错误。再也不会有“忘记运行代码检查器”的情况了！

2. 分支策略：选择你的工作流

2.1. Git Flow——大型项目的经典选择

对于Kotlin单体应用或具有严格发布周期的项目，经典的Git Flow非常适用。主要分支：

\n
• main——仅包含生产环境中的稳定代码。
\n
• develop——开发集成分支。
\n
• feature/*——每个新功能。
\n
• release/*——发布准备（修复错误、更新版本）。
\n
• hotfix/*——生产环境的紧急修复。
\n

Kotlin示例：你正在开发一个新的协程处理功能。创建分支feature/coroutine-flow，进行开发，然后合并到develop。当功能足够发布时，创建release/2.1.0，在其中修复错误，然后才合并到main。

2.2. GitHub Flow——适用于CI/CD和快速发布

如果你在Ktor或Spring Boot上编写微服务并每天部署，Git Flow会显得过于复杂。使用GitHub Flow：

\n
• main分支始终准备好部署。
\n
• 每个任务对应一个feature/名称分支。
\n
• 完成后——发起Pull Request、代码审查、自动化测试、合并到main。
\n
• 合并后立即部署（理想情况下）。
\n

非常适合测试覆盖率高的Kotlin项目。

2.3. Trunk-based——适合勇敢者

在初创公司工作或做个人项目？Trunk-based（所有人都通过短提交直接提交到main）可以加速开发，但需