嵌入式开发新手 Git 工作流指南：从零到团队协作

当我们还不太熟悉 Git，但入职新公司后开发工作又必须快速上手时，一套清晰、连贯的日常 Git 操作指令就显得至关重要。它能帮助你高效、规范地将代码上传到公司服务器，并与团队无缝协作。

下面将按照 「基础准备 → 核心开发流程 → 日常问题处理」 的逻辑，梳理一份新手也能轻松掌握的 Git 常用命令流，每个关键步骤都附带解释说明。

一、环境配置准备

如果是第一次操作公司的项目，请先完成以下基础配置和代码克隆操作：

# 1. 配置全局用户信息（提交记录会显示，需和仓库平台账号一致）
git config --global user.name "你的用户名"
git config --global user.email "你的注册邮箱"

# 2. 克隆远程仓库到本地（替换为你的真实仓库地址）
git clone https://github.com/xxx/xxx.git

# 3. 进入项目目录（后续所有命令都在该目录下执行）
cd 项目文件夹名称

二、日常开发核心命令流

日常开发强烈建议遵循 「主分支不直接开发，功能分支独立开发」 的原则。其核心流程如下：

步骤1：拉取主分支最新代码

开始新功能前，确保本地主分支（main / master）是最新的，这能最大程度避免后续的合并冲突。

# 切换到主分支
git checkout main # 如果是 master 分支，替换为 git checkout master

# 拉取远程主分支的最新代码
git pull origin main

步骤2：创建并切换到功能分支

为你的新功能或修复创建一个独立的分支。分支命名建议规范，例如 feature/功能名、bugfix/问题编号。

# 创建并切换到新分支（示例：开发用户登录功能）
git checkout -b feature/user-login

步骤3：开发过程中的常规操作

在功能分支上进行编码，并定期提交你的更改。

# 1. 随时查看文件修改状态（必用，确认修改范围）
git status

# 2. 将修改的文件加入暂存区（. 代表全部修改，也可指定单个文件）
git add .  # 全部修改
# git add src/login.vue  # 仅添加指定文件

# 3. 提交代码（提交信息要清晰，推荐格式：类型(模块): 描述）
# 类型：feat(新功能)、fix(修复)、docs(文档)、style(格式)、refactor(重构)等
git commit -m "feat(登录): 实现手机号+验证码登录功能"

# 4. （可选）提交后发现漏改，补充提交（避免产生多个无意义的commit）
git add 遗漏的文件路径
git commit --amend  # 修改最近一次提交，不会新增commit记录

步骤4：推送分支到远程仓库

将本地功能分支推送到远程仓库，以便团队其他成员查看或进行代码审查。

# 第一次推送该分支，-u 参数用于关联远程分支（后续直接 git push 即可）
git push -u origin feature/user-login

# 后续在该分支上修改后推送（已关联分支）
git push

步骤5：功能完成后合并到主分支

功能开发并测试完毕后，需要将其合并回主分支。这里有两种常见方式。

方式1：本地合并（适合小型团队或个人项目）

# 1. 切回主分支并拉取最新代码（再次确认无新修改）
git checkout main
git pull origin main

# 2. 合并功能分支到主分支
git merge feature/user-login

# 3. 推送合并后的主分支到远程
git push origin main

方式2：提 Merge Request / Pull Request（MR/PR，推荐团队协作）

无需在本地执行合并命令。在推送功能分支到远程后，直接前往 Git 平台（如 GitLab 或 GitHub），手动提交一个「合并请求」。等待同事或负责人审核通过后，由有权限的管理员在平台上完成合并操作。这是现代 团队协作 中更规范、更安全的流程。

步骤6：清理分支（合并后删除）

功能成功合并后，为了保持仓库的整洁，可以删除已合并的分支。

# 删除本地功能分支（-d 仅删除已合并的分支，-D 强制删除未合并的，慎用）
git branch -d feature/user-login

# （可选）删除远程功能分支
git push origin --delete feature/user-login

三、日常问题处理常用命令

开发过程中难免会遇到需要回退、查看历史或解决冲突的情况。

1. 撤销工作区修改（未 add 的文件）

恢复指定文件到最近一次 commit 时的状态，丢弃所有未暂存的修改。

git checkout -- 文件名  # 示例：git checkout -- src/login.vue

2. 撤销暂存区修改（已 add 但未 commit）

将已添加到暂存区的文件移回工作区，你可以重新修改它。

git reset HEAD 文件名  # 示例：git reset HEAD src/login.vue

3. 查看提交日志

需要追溯代码修改历史或寻找特定版本号时使用。

# 一行简洁显示所有提交（版本号+提交信息）
git log --oneline

# 查看指定文件的提交记录
git log 文件名

4. 解决合并冲突

合并时出现冲突是常态，不要慌张，按步骤处理即可。

# 1. 冲突发生后，先查看哪些文件冲突了
git status  # 会标注「both modified」的冲突文件

# 2. 打开冲突文件，手动修改。文件内冲突标记类似如下：
# <<<<<<< HEAD （当前分支的代码）
# 你的代码
# ======= （分隔线）
# 对方的代码
# >>>>>>> feature/user-login （待合并分支的代码）

# 3. 手动解决冲突（决定保留哪部分或如何整合）后，标记冲突已解决
git add 冲突文件名

# 4. 完成合并提交
git commit -m "fix: 解决登录功能合并冲突，调整验证码逻辑"

这里重点聊聊合并冲突：

合并冲突最核心、最常见的触发时机就是执行 git merge feature/user-login 时。解决冲突的操作也正是在这个合并被中断的阶段完成。

因为当你执行 git merge 时，Git 会尝试自动合并两个分支的代码：

• 如果两段代码修改的是不同文件、或同一文件的不同位置，Git 能自动完成合并，整个过程无感知。
• 如果两段代码修改了同一个文件的同一行（或相邻行），Git 无法判断保留哪一份修改，就会中断 merge 流程，并提示冲突，此时你必须手动解决冲突才能继续完成合并。

另外，git pull 也常发生合并冲突，因为 git pull = git fetch（拉取远程代码） + git merge（合并到本地分支）。如果远程分支和你本地分支修改了同一处代码，git pull 时会直接触发冲突，解决方式和上面完全一致。

这里是一个更完整的冲突解决示例：

# 1. 切到主分支，拉取最新代码
git checkout main
git pull origin main

# 2. 执行合并，触发冲突（Git 提示合并失败）
git merge feature/user-login
# 命令行输出类似：
# Automatic merge failed; fix conflicts and then commit the result.

# 3. 查看冲突文件（关键步骤）
git status
# 输出会标注冲突文件，比如：
# both modified:   src/login.c  # 表示这个文件两边都做了修改，有冲突

# 4. 手动解决冲突：打开 src/login.c，找到冲突标记并修改
# 5. 修改后保存，标记为「冲突已解决」
git add src/login.c

# 6. 完成合并提交
git commit -m “merge: 解决登录功能合并冲突，统一验证码逻辑”

# （可选）如果合并到一半想放弃，执行：
# git merge --abort  # 回到合并前的状态，不会保留任何修改

5. 回滚已提交的代码

如果发现某次提交的代码有问题，需要回退到之前的某个版本。此操作需谨慎，尤其在团队协作中。

# 1. 查看提交日志，复制要回滚到的版本号（前6-8位即可）
git log --oneline

# 2. 软回滚（保留工作区的修改，可重新审查后提交，推荐）
git reset --soft 版本号  # 示例：git reset --soft a1b2c3d

# 3. 硬回滚（彻底放弃目标版本之后的所有修改，谨慎！）
git reset --hard 版本号
# 若已推送到远程，需强制推送（团队协作前务必沟通！）
git push -f origin main

总结

1. 核心流程：牢记「拉取主分支→创建功能分支→开发提交→推送→合并→清理分支」这一 命令流，能帮你规避大部分协作问题。
2. 规范先行：提交信息和分支命名要清晰规范，便于追溯；git status 是高频命令，养成随时查看的习惯。
3. 谨慎操作：撤销（git reset）和强制推送（git push -f）等操作具有破坏性，在团队环境中使用前务必沟通。

掌握以上 Git 工作流，你就能从容应对嵌入式乃至大多数软件开发中的版本控制需求。如果你想深入探讨更多 DevOps 实践或团队协作工具，欢迎来 云栈社区 与其他开发者交流。