git add 必须在 git commit 之前执行，因为 Git 不自动跟踪工作区修改，需手动暂存改动；否则 commit 会提示 “nothing to commit”，即使文件已修改。
git add 和 git commit 的顺序不能颠倒
提交代码前必须先暂存修改，否则 git commit 会提示 “nothing to commit”，哪怕文件确实改了。Git 不自动跟踪工作区变更，得手动告诉它哪些改动要进本次提交。
常见错误是直接 git commit -m "msg" 而忘了 git add，尤其刚改完一个文件就急着提交时容易漏。如果改的是新文件（未被 Git 跟踪），还必须用 git add -A 或 git add .，只用 git add -u 会忽略它。
-
git add .：暂存当前目录下所有已跟踪文件的修改 + 新建文件（不包括被.gitignore忽略的） -
git add -u：只暂存已跟踪文件的修改和删除，不处理新文件 -
git add -A：等价于git add .在大多数场景，更稳妥
push 前要确认远程分支是否存在且匹配
执行 git push 时，如果本地分支没设置上游（upstream），会报错：fatal: The current branch xxx has no upstream branch. 这不是网络问题，是 Git 不知道该推到远程哪个分支。
最简解法是首次推送时加 -u 参数：git push -u origin main（假设远程主干叫 main）。之后再 git push 就能省略参数。注意分支名要和远程一致——GitHub 新仓库默认是 main，老项目可能是 master，输错会新建一个同名远程分支，导致后续 git pull 拉不到预期更新。
- 查远程分支列表：
git ls-remote --heads origin - 查本地分支关联的上游：
git branch -vv，看有没有[origin/xxx] - 手动设置上游（补救）：
git branch --set-upstream-to=origin/main main
pull 和 push 不是镜像操作，冲突得先解决再提交
别人在你 push 前已更新远程，你再 git push 会被拒绝，提示 Updates were rejected because the remote contains work that you do not have locally. 这时候不能硬推（--force），得先拉取合并。
运行 git pull 实际是 git fetch + git merge，如果本地修改和远程有重叠，会触发合并冲突。此时 git status 显示 both modified，必须手动编辑冲突文件，删掉 <<<<<、======、>>>>> 标记并保留正确逻辑，然后 git add <file> 标记为已解决，最后 git commit（Git 会自动生成合并提交信息）。
- 想避免自动合并？用
git pull --rebase，把你的提交“重放”到最新远程基础上，线性历史更干净 - 但 rebase 后如果已推过，再
git push会失败，必须加--force-with-lease（比--force安全） - 别在共享分支上 rebase，仅限自己本地未推送的提交
同步远程更新不只是 push，fetch 和 merge 也常被忽略
很多人以为 git push 后就“同步完成”，其实这只是把本地更新发出去；其他人是否拉取、CI 是否构建、线上是否部署，都不归 Git 管。真正影响协作效率的，是及时获取他人更新——而这靠 git fetch 和 git merge（或 git pull）。
直接 git pull 会立即合并，有时你想先看看别人改了啥再决定怎么合，这时应分两步：git fetch 把远程引用（如 origin/main）更新到本地，再用 git log HEAD..origin/main 查差异，确认无风险后再 git merge origin/main。
-
git fetch是安全的，不改工作区，只更新远程跟踪分支 -
git pull=git fetch+git merge（默认）或git rebase（加--rebase） - 团队多人共用一个分支时，建议每天开工前先
git fetch && git log --oneline HEAD..origin/main快速扫一眼
