git学习笔记1

• Git 对象数据库的本质
  • “工作目录”不仅是文件目录，在逻辑上更可视作 Git 数据库的展示与交互界面，或理解为一个动态的“前端视图”。
  • Git 的核心是一个内容寻址的对象数据库，工作目录是其用户操作层面的外在表现。
• 文件在 Git 中的不同状态
  • Untracked：未被 Git 纳入版本管理，处于数据库监管之外。
  • Staged：已暂存，准备纳入下一次提交。
    • 可进一步区分为：更改未暂存（unstaged changes）和已暂存待提交（changes to be committed）。
  • Committed：已提交至版本历史，持久存储在对象数据库中。
• git restore：重置工作区或暂存区
  • 用于将文件从指定源（如提交或暂存区）恢复至工作区，本质是根据源重置文件内容。
  • 对未暂存的修改：执行 git restore <file> 将丢弃工作区改动（恢复为暂存区或 HEAD 状态）。
  • 对已暂存未提交的修改：使用 git restore --staged <file> 可将文件从暂存区撤出，但保留工作区改动。
  • 与 git reset 按提交历史整体回退不同，restore 更侧重于对单个文件或部分内容的恢复。
• git stash：临时保存工作现场
  • 将当前所有已跟踪文件的修改压入栈中，便于清理工作区。
  • 默认不处理未跟踪文件（untracked），可使用 -u 选项一并保存。
  • “工作区污染” 指：工作目录或暂存区中存在未提交的更改，可能阻碍分支切换等操作。
• 暂存区与工作区的特点
  • Git 具有单一的暂存区（stage/index）和对象数据库，但可支持多个工作目录视图。
  • 工作区污染：
    • 未跟踪文件（untracked）最易造成干扰。
    • 已修改未暂存或已暂存未提交的文件，在切换分支时可能被 Git 阻止或携带至新分支。
  • 暂存区污染：
    • 暂存区是全局的，不随分支切换自动重置。
    • 已暂存或未暂存的更改可能被带入其他分支，并在提交后入库。
  • 建议频繁使用 git status 查看状态，必要时通过 git stash 清理工作现场。
• 处理变基与合并冲突
  • 在变基或合并过程中发生的所有冲突解决操作，若使用 --abort 选项，将会全部丢弃，回到操作前状态。
• Merge 的工作机制
  • 通常在接收合并的分支（如主分支）上执行合并操作。
  • 合并成功会生成一个“合并提交”，记录分支汇集历史（默认不直观显示被合并分支的具体节点）。
    • 两种例外不生成合并提交：发生冲突（需手动解决）、快进合并（FF，集成分支无新提交）。
  • 使用 git log --graph 可图形化查看合并历史及分支结构。
• 冲突解决流程
  • 合并（merge）：
    • 使用 git status 查看冲突文件。
    • 手动解决冲突后，用 git add <文件> 标记冲突已解决（Git 允许标记未完全解决的文件，需谨慎）。
    • 全部冲突标记后，执行 git commit 完成合并。
    • git merge --abort 可彻底中止合并过程。
    • Merge 一次性尝试合并所有变更，要求统一解决所有冲突后提交。
  • 变基（rebase）：
    • 解决流程类似，每应用一个提交遇到冲突都需处理。
    • 解决后使用 git rebase --continue 继续，或 --skip 跳过当前提交，--abort 完全中止变基。
    • Rebase 逐个提交应用变更，在每个冲突点暂停，要求逐一解决。
• 变基（Rebase）使用须知
  • 普通变基：用于整理提交历史，使其更线性、清晰。
  • 交互式变基（-i）：提供更精细的提交修改、合并、删除等操作。
  • 重要原则：不要对已推送至公共/共享仓库的分支执行变基。
  • 变基会创建新提交（哈希值改变），改写历史。
  • git pull --rebase 相当于先抓取更新再变基，而非合并，可保持历史线性。
• 实用技巧
  • git add -p：交互式选择更改块暂存，精细化控制提交内容。
  • git commit --amend：修补最新提交（可修改提交信息或纳入当前暂存区改动），适用于提交后立即发现小错误的情形。