Git——使用总结

• 参考链接：
  • 值得参考的博客：https://segmentfault.com/a/1190000008617626
  • 更详细解释一般直接查看 git (command) -h 即可

---

总体概况总结

• 简单结构图：
• 全局结构图：

---

常见的分支管理

• 查看本地分支

  git branch

• 查看所有分支(包括远程)

  git branch -a

• 删除本地分支

  # 安全删除（safe delete），Git 会检查该分支是否已经完全合并到当前分支（或者 HEAD 所指的分支）；如果分支上还有未合并的提交，Git 会阻止删除
  git branch -d branch_name
  # 强制删除（force delete）；等价于：'git branch --delete --force <branch>'，不管分支是否已合并，都会直接删除
  git branch -D branch_name

• 删除远程分支

  git push origin :branch_name

  • 将空的东西推送到远程的branch_name分支，也就是删除远程分支

• 新建本地分支

  # 将远程分支拉取到本地的 Repository 中，但不修改本地工作目录，如果本地分支不存在，则新建分支
  git fetch origin master:branch_name
  # 从当前分支 fork 一个分支出来
  git checkout -b branch_name
  # 若 branch_name 分支在本地工作目录不存在，但是 origin 上存在，则本地工作目录上会创建 branch_name
  git checkout branch_name

• 新建远程分支

  git push origin master:branch_name

  • 将本地分支推送到远程，如果branch_name不存在，则新建分支

---

冲突管理

远程分支和本地分支有不同的 commit

• git pull和git push均产生reject异常

• 使用下面语句拉取远程分支到本地old分支并合并

  git fetch origin master:old
  git merge old

• 上面两句等价于

  git pull origin master:old

  • 注意：不建议使用 pull 拉取其他分支，容易产生操作失误

• 如果能够快速合并，也就是相同文件没有同时被不同提交修改：

  • 上面的语句将弹出一个合并窗口提示输入合并这个操作(提交)的 Comment，按照提示提交保存即可
  • 保存后自动生成一个以刚才的 Comment 命名的提交

• 不能快速合并时

  • 上面的语句会提示我们哪些文件有合并冲突需要解决的
  • 我们需要根据提示找到并修改文件中冲突
  • 然后重新提交(像正常提交代码一样即可)

    git add .
    git commit -m "  "

• 合并完成后删除多余分支

  git branch -d old

附录：fetch 和 pull 两者比较：

git pull == git fetch + git merge
git pull origin master:old == git fetch origin master:old + git merge old

---

git diff

• git diff A B
  • 基于 A 查看 B 有何变化
  • 显示时会自动识别为基于 a/A 看 b/B 有何变化

---

文件恢复

恢复本地缓冲区文件到disk

• 恢复某个文件：git checkout -- xx/xx.py
• 恢复某个文件夹下所有文件：git checkout -- xx/*
• 指定恢复某个分支到指定文件：git checkout master -- xx/xx.py

恢复HEAD到缓冲区

• 仅恢复到缓冲区：git reset or git reset HEAD
• 不仅恢复到缓冲区，同时恢复到disk： git reset HEAD --hard

---

从远程拉取一个新分支

• 从远程拉取分支到本地：git fetch origin xxx
  • 此时使用 git branch -a 可以看到远程分支引用在本地
  • git fetch origin xxx 后，FETCH_HEAD 会指向远程 xxx 分支
    • FETCH_HEAD 是个临时的引用，可以对该分支做任意想做的操作，比如此时可用 git merge FETCH_HEAD 来合并新拉取的分支
• 创建本地同名新分支：git checkout xxx
  • 必须同名

---

git clone 进阶

• git clone ssh:xxx 默认拉取master分支
• git clone -b [branch] ssh:xxx 拉取 [branch] 分支

---

git clone 仅拉取某个分支

• 仅拉取某个分支，用于大型项目

  git clone --single-branch --branch [branch] ssh:xxx

• 如果想进一步降低下载量（不关心历史记录），可以加上 --depth 1 参数

• 注意：如果使用下面的命令（即不添加 --single-branch 参数），会拉取所有分支内容 ，但是本地仅检出目标分支

  git clone --branch [branch] ssh:xxx
  # 等价简写形式
  git clone -b [branch] ssh:xx

---

删除本地跟踪远程分支

• git branch -d --remotes origin/xxx
  • 测试发现：git 1.7.1会报错，git 2.24.3没问题

---

git pull 和 git push 默认分支设定

• git branch --set-upstream-to=origin/xxx xxx
  • 经测试：git 1.7.1会报错，git 2.24.3没问题（但git pull不会生效）

---

添加文件到.gitignore

• 如果文件已经被添加到Git仓库中（常常出现在一些不规范的项目中），则可以考虑使用以下步骤解决：
  • 假设Git仓库中已经把.DS_Store添加到Git仓库中
  • 首先拉取项目并在.gitignore中添加*.DS_Store
  • 执行git rm --cached *.DS_Store, 从缓冲区中删除所有*.DS_Store文件，但保留本地文件
  • 执行git add .并重新提交

---

在目录内部忽略自身

• 可以不修改外部的 .gitignore 文件（即不修改项目根目录下的 .gitignore 文件），通过在某个目录下增加 .gitignore 文件来定义子目录下的忽略规则

• 用法示例：./venv/.gitignore

  *

  • 表示忽略该 ./venv/ 目录下的所有文件

• 这种方法很有益于管理本地多余的文件夹，因为不需要修改到 项目本身的 .gitignore 文件

---

Git 标签的使用

• Git 标签（tag）是用于标记仓库中特定提交节点的引用，常用于版本发布（如 v1.0.0）、重要里程碑等场景，方便后续快速定位和回溯

标签类型

• 轻量标签（lightweight）
  • 仅作为某个提交的“指针”，不包含额外信息（如创建者、时间、注释），本质是一个 commit_id 的引用
  • 适合本地临时标记
• 带注释标签（annotated）
  • 完整的标签对象，包含标签名、创建者、时间戳、详细注释等信息，会被 Git 永久存储在仓库中
  • 适合正式版本发布（推荐使用）

创建标签

• 创建带注释标签（推荐）

  git tag -a <标签名> -m "<标签注释>"
  # 示例：git tag -a v1.0.0 -m "正式发布 v1.0.0 版本"

  • -a：指定创建带注释标签
  • -m：直接添加注释（若省略，会打开编辑器输入）

• 给历史提交打标签：默认标签是打在当前最新提交上，若要给历史提交打标签，需指定 commit_id （可通过 git log 查看）：

  git tag -a <标签名> <commit_id> -m "<注释>"
  # 示例: git tag -a v0.9.0 a1b2c3d -m "修复 bug 后的预发布版本"

• 创建轻量标签：无需 -a 和 -m，直接指定标签名：

  git tag <标签名>  # 默认为当前提交
  # 或指定历史提交
  git tag <标签名> <commit_id>

查看标签

• 列出所有标签（仅列出标签名）

  git tag

• 按字母顺序排列（非创建时间，仅列出标签名），可加筛选（如查看 v1 开头的标签）

  git tag -l "v1.*"  # -l 表示筛选（list）

• 查看标签详情：查看带注释标签的完整信息（包括创建者、时间、注释、对应提交等）

  git show <标签名>
  # 示例：git show v1.0.0 # 查看 `v1.0.0` 的详情

• 列出远程标签（包含标签 id 和 commit_id 等）

  git ls-remote --tags origin

  • 列出的结果会同时包含标签自己的实体 id（如 v1.1.0） 和 对应的 commit_id （如 v1.1.0^{}）

• 列出本地标签（包含标签 id）

  git show-ref --tags

推送和拉取远程仓库标签

• 创建的标签默认只保存在本地，需手动推送到远程仓库

• 推送单个标签

  git push origin <标签名>
  # 示例：git push origin v1.0.0

• 推送所有本地未推送的标签

  git push origin --tags

• 拉取远程仓库所有标签

  git fetch origin --tags

• 拉取远程仓库单个标签到指定标签

  git fetch origin refs/tags/v1.2.0:refs/tags/v1.2.0
  # 等价命令
  git fetch origin v1.2.0:refs/tags/v1.2.0 # 在不会引起误会的情况下，前面的前缀 refs/tags/ 可以删除，但后面的不可以

  • 本地会新增 v1.2.0 标签，指向与远程该标签相同的 commit
  • 注：refs/tags/v1.2.0 中的 refs/tags/ 是标签的前缀完整命名，是必要的，否则会被当做 branch（实际上 branch 的完整命名是 refs/heads/xx）

删除标签

• 删除本地标签

  git tag -d <标签名>

• 删除远程仓库的标签：需先删除本地标签，再推送删除操作到远程：

  git tag -d <标签名>  # 先删本地
  git push origin --delete <标签名>  # 再删远程

检出标签（查看标签对应的代码）

• 标签是静态的（不可修改），检出标签时会进入“分离头指针”状态（detached HEAD），此时修改不会影响任何分支，适合临时查看历史版本：

  git checkout <标签名>

• 若要基于标签修改代码，需创建新分支：

  git checkout -b <新分支名> <标签名>

标签管理最佳实践

• 命名时，建议使用语义化版本（如 v<主版本>.<次版本>.<修订号>，例 v2.1.3），清晰区分版本迭代
• 优先使用带注释标签，包含完整信息，便于协作和追溯
• 推送标签前确认，标签一旦推送到远程，尽量避免删除（尤其是已发布的版本标签），如需删除需同步团队
• 发布版本时，在 release 或 main 分支打标签，确保标签对应稳定代码

---

Git 配置相关

• 用户配置查看

  # 查看所有配置（含用户信息）
  git config --list
  
  # 查看「当前生效」的用户名/邮箱
  git config user.name 
  git config user.email
  
  # 查看「当前仓库」的用户配置（仅对当前项目生效）
  git config --local user.name
  git config --local user.email
  
  # 查看全局「用户」配置（对所有仓库生效，默认常用）
  git config --global user.name
  git config --global user.email
  
  # 查看系统级用户配置（需管理员权限，Windows 可能需要以管理员打开终端，这个命令很少用）
  git config --system user.name
  git config --system user.email

• 用户配置设置

  # 全局配置（所有仓库通用，推荐）
  git config --global user.name "用户名"
  git config --global user.email "邮箱"
  
  # 仅当前仓库配置（覆盖全局，适合单独项目需求）
  git config --local user.name "用户名"
  git config --local user.email "邮箱"