Git操作全攻略：从基础上传到冲突解决

1. Git基础操作：从本地到远程的完整上传流程

作为现代开发者的版本控制利器，Git的操作看似简单却暗藏玄机。很多新手在第一次上传代码时总会遇到各种"灵异事件"——明明执行了命令却看不到文件更新，或者冲突解决后代码莫名其妙消失了。下面我将拆解标准的Git上传流程，并分享几个实际项目中总结的黄金法则。

1.1 文件追踪三步骤

标准的Git上传包含三个关键操作，我习惯称之为"上传三连"：

bash复制git add ./           # 将工作区变更存入暂存区
git commit -m "描述"  # 将暂存区变更存入本地仓库
git push             # 将本地仓库同步到远程

这里有个常见误区：很多人以为git add ./只能添加当前目录文件。实际上：

• git add . 会递归添加所有未被.gitignore过滤的文件
• git add * 则不会添加以点开头的隐藏文件
• 特定场景下建议使用git add -u只更新已跟踪文件

经验之谈：在大型项目中，我习惯先用git status查看变更清单，再针对性add文件。盲目使用git add ./可能会意外提交临时文件或敏感配置。

1.2 身份标识配置指南

当你在团队协作时看到这样的提交记录：

code复制Author: root <root@localhost>

基本可以确定是忘了配置用户信息。正确的全局配置方式：

bash复制git config --global user.name "你的真实姓名"
git config --global user.email "公司邮箱"

如果想为特定项目设置不同身份（比如个人开源项目），去掉--global参数在项目目录执行即可。验证配置是否生效可以用：

bash复制git config --list | grep user

2. 冲突解决：保留本地版本的权威方案

合并冲突是团队开发的家常便饭。当Git无法自动合并时，文件里会出现这样的标记：

code复制<<<<<<< HEAD
本地代码
=======
远程代码
>>>>>>> branch-name

2.1 全量保留本地修改

当确定要丢弃所有远程变更时，这套组合拳屡试不爽：

bash复制git checkout --ours .      # 对当前目录所有冲突文件采用本地版本
git add .                  # 标记冲突已解决
git commit -m "解决冲突"    # 提交合并结果
git push                   # 同步到远程

2.2 选择性保留策略

更常见的场景是需要混合处理不同文件。我曾处理过一个物联网项目合并，需要这样分类处理：

bash复制# 文本文件保留本地版本
git checkout --ours src/main.c

# 固件文件保留远程版本（注意特殊字符转义）
git checkout --theirs "firmware/jl_isd(授权).ufw"

# 配置文件手动合并
vim config/settings.ini    # 手动编辑解决冲突

# 最终提交
git add .
git commit -m "合并固件更新并保留主程序修改"

血泪教训：二进制文件（如.ufw、.bin）必须明确指定用--ours或--theirs，用文本合并工具打开会导致文件损坏。曾经有同事误操作导致设备变砖，不得不连夜重烧芯片。

3. 高级技巧：那些文档没写的实战经验

3.1 撤销操作的逃生指南

误操作时别慌，Git提供了完善的历史回退机制：

bash复制# 撤销add但保留修改
git reset HEAD file.txt

# 撤销最近一次commit（代码仍保留）
git reset --soft HEAD~1

# 彻底回退到某个版本（慎用！）
git reset --hard commit_id

3.2 提交信息规范模板

好的commit message应该像新闻标题一样清晰。我们团队采用的格式：

code复制类型(模块): 简明主题

• 变更背景（为什么改）
• 具体修改内容（改了啥）
• 影响范围（会影响谁）

示例：

code复制fix(网络模块): 修复WiFi频繁断开问题

• 由于看门狗超时导致连接中断
• 将心跳包间隔从30s调整为15s
• 影响所有使用WLAN模块的设备

3.3 忽略文件的最佳实践

.gitignore的配置直接影响仓库清洁度。建议：

code复制# 忽略操作系统文件
.DS_Store
Thumbs.db

# 忽略IDE配置
.idea/
.vscode/

# 忽略编译产物
*.o
*.bin
*.hex

# 但保留关键的版本化文件
!release/正式版.bin

有个冷知识：已经被跟踪的文件加入.gitignore不会自动失效，需要先执行：

bash复制git rm --cached 文件路径

4. 企业级Git工作流建议

在参与过多个大型项目后，我总结出这些黄金准则：

1. 分支策略：主分支保持可发布状态，功能开发在feature分支完成
2. 提交粒度：每次commit只做一件事，便于回退和code review
3. 推送频率：每天至少push一次到远程备份，但避免推送半成品
4. 合并前检查：执行git diff --check查找空白字符错误

对于嵌入式开发特别提醒：固件文件建议用Git LFS管理，否则仓库会急剧膨胀。曾经有个项目.bin文件直接提交，导致clone一次要30分钟。

最后分享一个实用别名配置（添加到~/.gitconfig）：

code复制[alias]
    lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
    st = status -sb
    co = checkout

这样用git lg就能看到漂亮的提交图谱，git st显示简洁状态，极大提升效率。记住，Git的强大在于理解其设计哲学——不是简单的文件备份，而是智能的变更管理。