研发实战：Git 规范化开发全流程指南

在现代研发团队中，Git 的作用远超简单的"代码保存"。它是一套保障代码质量、支持并行开发、追溯历史责任的协作系统。本文将带你走过从配置环境到成功上线的完整 Git 流程。

阶段一：初入项目（环境搭建与授信）

场景： 你刚加入新项目组，组长丢给你一个 Git 地址，你需要获得下载权限并把代码同步到本地。

1. 身份通行证：SSH 配置

为了安全，公司仓库通常不使用账号密码，而是识别你的电脑设备。

可以把 SSH 设置 想象成一种"免密通行证"。

为了让你彻底搞清楚底层逻辑，我把这个过程拆解成三个通俗易懂的环节：

1.1. 什么是 SSH 密钥？（身份证 vs 印章）

SSH (Secure Shell) 密钥是一对由算法生成的超长字符串，分为两个文件：

私钥 (id_rsa) ：保存在你本地电脑，绝对不能给别人看。它就像是你的印章。
公钥 (id_rsa.pub) ：可以公开。它就像是一个印泥模具，你把它交给公司平台（GitHub/GitLab）。

1.2. 为什么要把它设置到公司平台？

当你尝试 git clone 或 git push 时，公司服务器会发起一个"挑战"：

服务器问：你是谁？凭什么操作这个代码库？
你的电脑 ：用本地的私钥对一个数据包进行"签名"（盖章），发给服务器。
服务器检查 ：服务器拿着你之前上传的公钥去匹配这个签名。如果对上了，说明你确实拥有对应的私钥。
结果：验证通过，允许你下载或上传代码。

一句话总结： 平台通过你上传的公钥认出了你的电脑，从此你在这台电脑上操作代码，再也不用输入账号密码了。

1.3. 设置好了能做什么？

一旦你完成了 SSH 绑定，你的电脑就获得了该账号下的全套权限：

克隆 (Clone)：可以把公司的私有项目下载到本地。
拉取 (Pull)：同步同事更新的代码。
提交 (Commit & Push)：把你写的代码上传到服务器。
权限范围：只要你的公司账号有权限访问的项目，你这台电脑都能直接操作。

1.4. 关键细节提醒

唯一性 ：如果你换了新电脑，必须在新电脑上重新生成一套 SSH 密钥并再次添加到平台。
安全提示 ：在公司电脑上生成密钥很安全。但如果你是在网吧或别人的电脑上操作，千万不要留下你的私钥。
验证连接：设置完后，你可以输入以下命令测试是否成功（以 GitHub 为例）：

bash 复制代码

ssh -T git@github.com

如果看到 Hi XXX! You've successfully authenticated...，就说明你的"通行证"生效了。

具体流程：

生成密钥：

bash 复制代码

ssh-keygen -t rsa -b 2048 -C "your_email@company.com"

关联平台 ：执行 cat ~/.ssh/id_rsa.pub 查看公钥，将其复制并粘贴到 GitLab/GitHub 的 SSH Keys 设置中。
克隆项目：

bash 复制代码

git clone git@github.com:org/your-project.git

阶段二：开启新任务（隔离开发）

场景： 组长让你开发一个"用户登录"接口。记住：永远不要在公共分支直接写代码。

1. 寻找基准点

首先确认项目现在的"标准版"代码在哪里（通常是 master 或 dev），并更新到最新：

bash 复制代码

git checkout dev    # 切换到基准分支
git pull origin dev # 拉取最新代码，确保你是站在巨人肩膀上开始的

2. 创建特性分支 (Feature Branch)

基于最新的基准代码，开辟专属你的"私人实验室"：

bash 复制代码

# 命名规范：姓名/类型/描述
git checkout -b wyh/feature/login-api

为什么要加 -b？ 它代表"创建并直接切换过去"。

阶段三：开发与提交（版本快照）

场景： 你写了一上午代码，完成了接口的核心逻辑，准备下班吃饭。

1. 暂存与提交

将修改的代码打包成一个"快照"，并写好备注：

bash 复制代码

git add .
git commit -m "feat: 实现登录接口核心逻辑，支持手机号校验"

技巧： 提交信息建议遵循 Conventional Commits 规范（如 feat:, fix:, docs:），这会让你的简历看起来更专业。

阶段四：提测与合并（协作集成）

场景： 代码写完了，本地自测通过，现在需要把代码推到服务器上，让测试同学进行验证。

1. 推送分支到远程

你的本地分支在服务器上是不存在的，需要第一次手动建立联系：

bash 复制代码

git push -u origin wyh/feature/login-api

2. 合并到发版分支 (Release)

测试验证无误，代码准备发版。这是最关键的一步：

同步目标分支 ：切换到发版分支（如 release-v1.0）并拉取最新，防止覆盖别人刚合进去的代码。

bash 复制代码

git checkout release-v1.0
git pull origin release-v1.0

合并代码：将你的功能分支合并进来。

bash 复制代码

git merge wyh/feature/login-api -m "merge: 合并登录功能到发版分支"

推送到远程：

bash 复制代码

git push origin release-v1.0

阶段五：突发状况（冲突处理）

场景： 在合并（merge）或拉取（pull）时，终端跳出红色的 CONFLICT。

处理原则：

不要慌：这只是 Git 无法判断两行不同的代码哪行更好。
人工介入：打开冲突的文件，你会看到：

text 复制代码

<<<<<<< HEAD
本地现有的代码（可能别人合进来的）
=======
你刚写好的代码
>>>>>>> wyh/feature/login-api

决策：找相关同事沟通，决定保留哪部分，删掉冲突标识符。
重新提交：

bash 复制代码

git add .
git commit -m "fix: 解决合并冲突"
git push

总结：研发 Git 操作 Checklist

环节	动作	命令摘要	避坑指南
准备	同步	`git pull`	动公共分支前必做，防止版本脱节
开启	创建	`git checkout -b`	分支名要有辨识度，严禁在 master 开发
过程	暂存	`git add` + `commit`	提交粒度要小，不要攒一坨代码才提交
交付	推送	`git push`	第一次推送记得加 `-u`
收尾	合并	`git merge`	遇冲突先沟通再操作，严禁盲目覆盖