在 Debian 上开始一个 Rust 项目时，Git 往往是第一批需要配好的基础工具。命令本身并不复杂，但真正影响后续协作是否顺畅的，通常是远程分支、标签使用方式，以及 Cargo.toml 和 Cargo.lock 这类关键文件有没有正确纳入版本控制。
下面按“从本地起步到远程协作”的顺序，把 Debian 下 Rust 项目的 Git 使用流程重新梳理一遍。照着做，你不仅能把仓库搭起来，也能判断哪些步骤是必须做、哪些是推荐做，以及哪些细节最容易在团队协作里埋坑。
先在 Debian 上安装并配置 Git
安装 Git
在 Debian 终端里，先更新软件索引，再安装 Git：
sudo apt update
sudo apt install git安装完成后，可以用下面的命令确认是否生效：
git --version只要终端能正常输出版本号，就说明 Git 已经可用。
配置全局用户名和邮箱
如果不提前配置提交身份，后续提交记录就很难在多人协作中准确追溯。通常建议直接写入全局配置：
git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"这些配置会保存到 ~/.gitconfig 中。想检查当前全局配置，可以执行：
git config --global --list这一步虽然简单，但对后续提交记录、代码审查和责任追踪都很关键。
把 Rust 项目初始化为 Git 仓库
在项目根目录执行初始化
进入 Rust 项目的根目录，也就是包含 Cargo.toml 的目录，然后运行：
cd /path/to/your/rust/project
git init执行后，目录里会新增一个隐藏的 .git 文件夹，Git 的版本控制元数据都会保存在这里。本地仓库建好后，后续的暂存、提交、分支和标签操作才有意义。
按需关联远程仓库
如果项目需要同步到 GitHub、GitLab 等代码托管平台，建议尽早把远程仓库接上。先在平台创建仓库，例如：
https://github.com/username/your-rust-project.git
然后在本地执行：
git remote add origin https://github.com/username/your-rust-project.git添加完成后，可以用下面的命令核对远程地址：
git remote -v确认 origin 指向的地址正确，再继续后续推送操作会更稳妥。
完成首次提交并推送到远程
先暂存，再提交
第一次提交通常会把整个项目骨架一起纳入版本控制，因此可以直接把当前目录内容全部加入暂存区：
git add .随后创建提交记录：
git commit -m "Initial commit"如果只是初始化一个示例结构，也可以使用文中给出的思路，例如写成 “Add initial Rust project structure” 这类更具体的提交说明。提交完成后，历史记录可以通过下面的命令查看：
git log首次推送时注意主分支名称
本地提交完成后，就可以把内容推送到远程仓库。首次推送一般要顺带设置上游分支：
git push -u origin main如果远程默认分支还是旧命名方式 master，则改用：
git push -u origin master完成这一步后，后续通常直接执行 git push 就可以同步本地更新。
协作阶段常用的分支、标签与同步命令
用分支隔离功能开发
开发新功能时，不要直接在主分支上改。更常见的做法是新建功能分支：
git checkout -b feature/new-login开发完成后，切回主分支并合并：
git checkout main
git merge feature/new-login确认合并完成后，再删除已经用完的功能分支：
git branch -d feature/new-login这套流程的核心价值，是让主分支保持相对稳定，同时把不同功能的开发边界划清楚。
用标签标记可发布版本
如果某个版本已经具备发布意义，建议打标签而不是只靠提交信息查找。附注标签更适合正式版本：
git tag -a v1.0.0 -m "Release version 1.0.0"轻量标签也可以使用：
git tag v1.0.1区别在于，附注标签会保存更完整的说明信息，更适合版本发布管理。
标签创建后，可以单独推送某一个标签：
git push origin v1.0.0也可以一次性推送所有标签：
git push origin --tags获取远程代码与更新本地仓库
如果是从远程开始拿代码，直接克隆仓库即可：
git clone https://github.com/username/your-rust-project.gitgit clone 会自动创建项目目录，并完成本地仓库初始化。
仓库已有更新时，则可以拉取并合并远程主分支内容：
git pull origin main这一步适合日常同步协作进度，尤其是在多人同时修改同一项目时。
Rust 项目里最容易漏掉的 Cargo 文件
Rust 项目使用 Cargo 管理依赖时，至少有两个文件需要特别注意，它们都应该进入版本控制：
Cargo.toml：保存项目名称、版本号、依赖项等核心配置。Cargo.lock：记录依赖解析后的具体版本，用来保证团队成员和部署环境拿到一致的依赖结果。
提交时可以显式把它们加入暂存区：
git add Cargo.toml Cargo.lock这一点在 Rust 项目里非常关键。若遗漏 Cargo.lock，不同环境可能解析出不同依赖版本，最终导致“本地能编译、别人那里失败”这类问题。对个人项目来说，这能提高可复现性；对团队项目来说，它直接关系到构建一致性和交付稳定性。
一套适合 Debian Rust 项目的基本做法
如果把整套流程压缩成最实用的版本，顺序通常就是：先安装并配置 Git，再在包含 Cargo.toml 的目录里执行 git init，随后完成首次提交、关联远程并推送。
进入日常开发阶段后，重点就转向分支管理、版本标签，以及对 Cargo.toml 和 Cargo.lock 的稳定维护。前面的命令都不算复杂，但这些细节是否做到位，决定了 Rust 项目后面是顺畅协作，还是反复踩坑。
