很多新手觉得 Git 不好用，它命令多、概念抽象（如分支、提交、合并、暂存区等），且初期容易遇到 “冲突解决”“代码回滚失误” 等问题。但企业普遍要求使用 Git，因为它完美适配了团队协作、版本管理、流程规范等企业级开发的核心需求，是当前最成熟、最高效的分布式版本控制系统。企业选择工具的标准，不是 “好不好上手”，而是 “能否支撑团队效率、降低协作风险、保障代码安全”，Git 在很多方面几乎无可替代。

1.代码提交后在 Git 上看不到提交记录，通常是因为提交操作未完成闭环，或本地与远程仓库存在同步问题。

git commit 只是将修改提交到本地仓库，而远程仓库的记录需要通过 git push 同步。应该执行 git log 查看本地提交记录，确认是否有你刚提交的记录（能看到说明本地提交成功）。若本地有记录但远程没有，执行 git push origin <分支名>（如 git push origin main）推送即可

也有可能是提交到了错误的分支。可能在本地新建了分支（如 feature/test）并提交，但远程仓库默认展示的是 main 或 develop 分支，导致 “看不到”。这时候执行 git branch 查看当前所在分支（带 * 的分支）。登录远程仓库，手动切换到你提交的分支（如 feature/test）查看记录

还有可能是本地仓库与远程仓库关联错误，本地项目未正确关联远程仓库，或关联的是其他仓库（如个人仓库而非公司仓库），导致 git push 实际推送到了错误的远程地址。执行 git remote -v 查看远程仓库地址，确认是否与目标仓库一致。若地址错误，重新关联：

git remote set-url origin <正确的远程仓库地址>  # 修改关联
git push origin <分支名>  # 重新推送

而有时候会遇到这样的问题，这个错误表示远程仓库有您本地没有的提交，Git 拒绝直接推送以避免覆盖远程的更改，需要先整合远程更改到本地。

可以先拉取远程并合并

git pull origin master

# 如果有冲突，解决冲突后再次提交
git add .
git commit -m "解决合并冲突"
git push origin master

如果还是不能推送，问题可能是缓冲区里已经有一个其他提交 （本地有1个提交待推送），但工作目录中还有未暂存的更改（.idea目录下的IDE配置文件）当然也有可能本地分支名称是 master，但远程跟踪的是 origin/ma

# 1. 先处理未暂存的更改（根据是否需要决定）
git restore ../.idea/*  # 如果不需这些文件

# 2. 确保跟踪正确的远程分支
git branch --set-upstream-to=origin/master master

# 3. 拉取并合并远程更改
git pull origin master

# 4. 推送提交
git push origin master

2.在 main 分支（或其他保护分支）直接写代码并提交，而不是在新建的功能分支上开发，导致主分支被污染，甚至影响线上代码。

已提交代码到错误分支：
用 git log 记下最新提交的 commit ID（如 a1b2c3d）。
切换到正确的目标分支（如 feature/new）：git checkout feature/new。
将错误分支的提交 “复制” 到当前分支：git cherry-pick a1b2c3d（如需复制多个提交，可写区间 git cherry-pick 提交1..提交2）。
回到错误分支，撤销刚才的提交（不影响代码）：git reset --soft HEAD~1（HEAD~1 表示撤销最近 1 次提交，--soft 保留工作区修改）。
把工作区的修改 stash 起来：git stash，切换到正确分支后恢复：git stash pop。
未提交代码（仅工作区修改）：
直接 stash 暂存修改：git stash。
切换到正确分支：git checkout 正确分支名。
恢复修改：git stash pop。

删除分支前未确认代码是否合并，导致代码丢失
错误表现：
删除分支（如 git branch -D feature/old）后，发现该分支的代码未合并到主分支，且没有备份，导致开发成果丢失。
解决方法：
预防：删除前先检查：
用 git branch -d 分支名 代替 git branch -D 分支名：-d 是安全删除，若分支未合并会提示错误（error: The branch 'xxx' is not fully merged），-D 是强制删除，无视合并状态。
删除前先切换到主分支，执行 git merge 分支名 确认是否已合并（无冲突且提示 “Already up to date” 说明已合并）。
已删除但需恢复：
用 git reflog 查找被删除分支的最后一次提交记录（找到类似 checkout: moving from feature/old to main 的记录，记下前面的 commit ID）。
基于该提交重建分支：git checkout -b 恢复的分支名 <commit ID>。

合并分支时用错 merge 和 rebase，导致历史混乱或冲突
错误表现：
频繁用 git merge 合并功能分支到主分支，导致提交历史出现大量 “合并节点”，难以追溯。
在公共分支（如 main）上用 git rebase，导致团队其他人的分支与远程不一致。
解决方法：
明确 merge 和 rebase 的使用场景：
git merge：适合合并公共分支（如 feature 合并到 main），会保留分支合并的完整历史（但可能产生冗余节点）。
git rebase：适合在个人功能分支上同步主分支代码（如 feature/new 基于 main 变基），让提交历史更线性（但会改写历史，禁止在公共分支使用）。
错误使用 rebase 导致冲突：
变基过程中出现冲突时，先解决冲突，然后 git add <冲突文件>，接着 git rebase --continue（不要 commit）。
若想放弃变基，执行 git rebase --abort。

3.历史版本代码丢失可能是什么原因

丢失代码看似严重，但其实绝大部分原因都是误用了回滚命令，而且由于 Git 会记录所有 HEAD 移动历史（包括回滚操作），只要曾提交过代码（未提交的 “工作区修改” 除外），几乎都能恢复。核心解决思路是：找到丢失代码对应的历史提交记录（Commit ID），再通过该记录重建代码或分支。

先明确：哪些 “回滚操作” 会导致 “代码丢失”？
常见的危险回滚操作及场景：
git reset --hard <版本号>：强制回滚到指定版本，且彻底删除 “当前版本到目标版本之间的所有提交记录”（工作区、暂存区内容也会被覆盖），是最易导致 “代码丢失” 的操作。
git checkout <旧版本号>：切换到历史版本后，在旧版本上修改了代码，但未提交就切回新版本，导致旧版本的 “未提交修改” 丢失。
误删包含关键提交的分支（如回滚后删除了原功能分支，后来发现需要该分支代码）

首先找到丢失提交的 Commit ID，Git 的 reflog 会记录所有 HEAD 的移动记录（包括 reset、checkout、commit 等），即使提交被 reset --hard 覆盖，也能在 reflog 中找到。然后恢复丢失的提交，再进行：
直接回到丢失的最新提交，如果想回到最后一个丢失的提交（如 C），执行：

git checkout c4d5e6f  # 切换到提交 C 的版本
# 此时处于“ detached HEAD ”状态（临时游离版本），需新建分支保留代码
git branch feature/v1-recover  # 基于当前游离版本，新建分支保存恢复的代码
git checkout feature/v1-recover  # 切换到新分支，代码已恢复

通过 IDE 本地历史恢复
主流 IDE（VS Code、IntelliJ IDEA、PyCharm 等）会自动保存文件的本地修改历史，即使文件被覆盖，也能找回：
VS Code：右键点击文件 → “本地历史记录” → 选择修改时间点恢复。
IntelliJ 系列：右键点击文件 → “本地历史” → “显示历史” → 选择版本恢复。

恢复步骤：
用 git reflog 找到被删除分支的 “最后一次提交”（同场景 1 第一步），例如找到 feature/pay 分支最后的提交 ID 是 f1g2h3j。
基于该提交重建分支：

git checkout -b feature/pay f1g2h3j  # 新建并切换到 feature/pay 分支，代码完全恢复

Git 设计的核心优势之一是 “不轻易丢失提交”—— 只要代码曾被 commit，就能通过 git reflog 找到历史记录并恢复。遇到 “回滚丢代码” 时，先通过 git reflog 定位丢失的 Commit ID，再根据场景选择 “重建分支” 或 “重置 HEAD”；未提交的修改则依赖 IDE 本地历史。

“提交” 是 Git 中最安全的操作，频繁小步提交（而非堆积大量修改后一次性提交），能最大程度降低 “代码丢失” 的风险。