在 Debian 上做 Go 项目开发，真正影响协作效率和构建稳定性的，往往不是业务代码本身，而是版本控制有没有成体系地做好。要解决这个问题，不能只盯着 Git 提交历史，还要同时把 Go Modules 的依赖版本管住，这样代码才能可追溯，构建结果也才可复现。
这篇文章按实际使用顺序，把 Debian 下 Go 项目的版本控制流程拆成环境准备、依赖管理、Git 仓库操作和日常最佳实践四部分。你可以直接照着命令执行，也能据此判断哪些步骤是必做、哪些是按项目复杂度选配。
先把基础环境准备好
安装 Git 并完成全局身份配置
在 Debian 上，Git 是代码版本控制的基础工具。先更新软件源，再安装 Git：
sudo apt update
sudo apt install git安装完成后，建议立即配置全局用户名和邮箱。后续每次提交都会记录这组信息，便于团队协作和历史追踪：
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"如果这一步没做，虽然 Git 仍然能工作，但提交记录的身份信息会不完整，后面追溯问题时会比较麻烦。
需要多版本 Go 时再安装 GVM
如果一台 Debian 机器上要同时维护多个 Go 项目，比如老项目使用 1.18，新项目使用 1.21，那么可以考虑安装 GVM（Go Version Manager）。这一步不是必需项，只在有多版本切换需求时才值得引入。
安装命令如下：
bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)安装后，把 GVM 加入 Shell 配置文件，例如 ~/.bashrc 或 ~/.zshrc：
echo '[[ -s "/home/youruser/.gvm/scripts/gvm" ]] && source "/home/youruser/.gvm/scripts/gvm"' >> ~/.bashrc
source ~/.bashrc常用命令包括：
- 列出可用版本：
gvm listall - 安装指定版本：
gvm install go1.20.5 - 切换版本：
gvm use go1.20.5 - 卸载版本：
gvm uninstall go1.20.5
如果项目只维护单一 Go 版本，这部分可以跳过，避免额外增加环境复杂度。
用 Go Modules 管住依赖版本
初始化模块：从 go.mod 开始
Go 1.11 之后，Go Modules 已经是官方推荐的依赖管理方式。相比早期的 GOPATH 模式，它最大的价值在于：依赖版本是显式记录的，团队成员拉到同一份代码后，更容易得到一致的构建结果。
在项目根目录执行：
go mod init github.com/yourusername/yourproject这里的 github.com/yourusername/yourproject 要替换成你的实际模块路径，通常就是仓库地址。执行后会生成 go.mod 文件，例如：
module github.com/yourusername/yourproject
go 1.20其中第一行定义模块路径，第二行标记当前使用的 Go 版本。后续所有依赖关系，都会围绕这个文件展开。
添加依赖和更新依赖怎么做
Go Modules 常见有两种依赖管理方式。
第一种是自动整理。先在代码里引入依赖，例如：
import "github.com/gin-gonic/gin"然后执行：
go mod tidy这条命令会自动下载需要的依赖，并同步更新 go.mod。
第二种是手动指定版本。适合你明确知道要锁定某个版本，或者只想升级到最新版本时使用：
go get github.com/gin-gonic/gin@v1.9.1 # 指定版本
go get github.com/gin-gonic/gin@latest # 更新到最新版执行后，除了 go.mod 会记录版本信息，还会生成或更新 go.sum。这个文件保存的是依赖包的加密哈希值，用来校验依赖内容是否被篡改，属于构建安全的一部分。
为什么 go.mod 和 go.sum 必须提交到 Git
很多初学者会把依赖文件当成“自动生成文件”忽略掉，但在 Go 项目里，go.mod 和 go.sum 其实是版本控制体系的一部分，必须提交到 Git。
这样做的直接收益有两个：
- 团队其他成员拉取代码后，执行
go mod tidy就能拿到一致的依赖版本； - 项目的构建结果更容易复现，排查“我这里能编译、你那里不能”的问题时更有依据。
因此，千万不要把这两个文件加入 .gitignore。
Git 仓库操作按这个顺序做
初始化本地仓库
进入 Go 项目目录后，先初始化 Git 仓库：
cd /path/to/your/golang/project
git init执行后，目录中会生成隐藏文件夹 .git，它保存了这个仓库的全部版本历史和元数据。
提交代码：暂存与提交缺一不可
Git 的一次完整提交，通常分成“加入暂存区”和“生成提交记录”两步。
- 添加所有文件：
git add . - 只添加某个文件：
git add filename.go - 提交变更：
git commit -m "Initial commit"
提交信息建议写清楚改动目的，否则后面查历史时只能看到一串难以理解的“update”或“fix”。
需要协作时，再关联远程仓库
如果项目要托管到 GitHub、GitLab 等平台，可以在本地仓库准备好后，再关联远程地址。先在平台上创建一个空仓库，然后执行：
- 关联远程仓库：
git remote add origin https://github.com/yourusername/yourproject.git - 首次推送：
git push -u origin main
这里要注意分支名。新项目通常使用 main，但一些老仓库可能仍然使用 master。
日常最常用的 Git 命令
除了初始化和首次提交，下面这些命令基本覆盖了日常开发：
- 创建分支：
git branch feature/login - 切换分支：
git checkout feature/login或git switch feature/login - 合并分支：先切到目标分支，例如
git checkout main，再执行git merge feature/login - 拉取更新：
git pull origin main - 查看状态：
git status - 查看日志：
git log
如果团队多人协作频繁，养成先看 git status、再提交和切分支的习惯，会少很多误操作。
.gitignore 应该忽略哪些内容
Go 项目里有些内容不应该进入版本库，比如编译产物、IDE 配置、环境变量文件。可以在项目根目录创建 .gitignore，写入以下内容：
# Go
/bin/
/vendor/
*.exe
*.test
*.prof
# IDE
.vscode/
.idea/
# 环境变量
.env然后执行：
git add .gitignore这样可以避免无关文件污染仓库，同时保留真正需要纳入版本控制的源码和依赖描述文件。
让版本控制真正稳定可用的几个习惯
发布版本时打标签
当项目进入可发布状态，建议使用 git tag 给稳定版本打标签，例如 v1.0.0：
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0这样做的好处是，后续定位线上版本、回滚历史版本，或者给外部依赖方提供明确发布点时，都更方便。
定期清理依赖，保持模块文件同步
随着开发推进，项目里可能会出现已经不再使用的依赖。定期执行 go mod tidy，可以清理无用依赖，并让 go.mod 和 go.sum 保持同步状态。
这一步看起来简单，但对长期维护的仓库很重要。依赖越干净，后面升级、审计和排错的成本越低。
分支策略尽量从一开始就定清楚
如果项目是多人协作，推荐提前约定基本分支模型：
main：稳定、可发布代码develop：日常开发分支feature/xxx：功能开发分支fix/xxx：问题修复分支
核心原则很简单：不要直接在 main 上长期开发。把稳定分支和开发分支分开，后续无论是发版还是回滚，都会轻松很多。
结语：Git 管历史，Go Modules 管依赖
在 Debian 下做 Go 代码版本控制，最重要的不是多学几个命令，而是形成一套稳定流程：Git 负责记录代码历史，Go Modules 负责固定依赖版本，两者一起使用，才能真正支撑团队协作和可复现构建。
如果是个人小项目，最少也要做到 git init、提交 go.mod/go.sum、配置好 .gitignore。如果是团队项目，再补上分支策略、远程仓库和标签管理，整个版本控制体系就基本完整了。
