my-git

Learning Git: from Understanding to Judgment

English 中文

Read why learn Git in the AI era, then follow understand the design → verify a decision → manage change. Look up commands as needed. Each stage should help you explain behavior and predict the effect of changing a condition.

This page arranges only the ten Git conceptual topics. When you need to choose between conceptual learning, one engineering change, and team collaboration, use the knowledge map.

Part one: understand the design

The table below is the unified order for ten topics. Each topic has paired Chinese and English articles, an interactive page, and a runnable temporary-repository lab. Topics 01 through 03 are the existing interactive topics; topics 04 through 10 are the seven added in this delivery. Available material and passing scripts do not establish that a reader has mastered it; that still needs evidence from prediction, reproduction, and transfer.

Order Core question Article, interactive, and lab Judgment exercise
01 Snapshots and state What do editing, staging, and committing record? Article · Interactive · Lab After editing again after add, which version is committed?
02 Object graph What belongs to commits, trees, and blobs? Article · Interactive · Lab Why can two paths share a blob?
03 Index What is the next commit draft? Article · Interactive · Lab How can one file contribute only some edits?
04 References and HEAD How do branches, tags, HEAD, and detached HEAD relate? Article · Interactive · Lab Does moving a branch change the old commit?
05 Reachability and recovery Can an unnamed commit be recovered? Article · Interactive · Lab Why is reflog not a permanent backup?
06 Merging and ancestry How does Git understand divergent histories? Article · Interactive · Lab Does a conflict-free merge imply compatible behavior?
07 Replay and rewriting Why does rebase produce new commits? Article · Interactive · Lab Why does rewriting shared history need coordination?
08 Remotes and synchronization How does origin/main differ from remote main? Article · Interactive · Lab Does fetch necessarily change working files?
09 Worktrees and concurrency Which state is shared and which is isolated? Article · Interactive · Lab Why can agents with separate branches still interfere?
10 Storage and maintenance How are snapshots stored and queried efficiently? Article · Interactive · Lab Do graph edges describe physical disk layout?

Maintainers can run bash scripts/run-git-learning-labs.sh to regress the ten labs, three existing reading experiments, one local agent-change acceptance exercise, and one command-safety regression. It verifies only scripted temporary local scenarios; it does not measure reader learning or establish production state.

Predict, manipulate the diagram, read the chapter, reproduce it in a temporary repository, then change one condition. Recovery precedes history rewriting so dangerous operations arrive with the necessary context.

Part two: apply the ideas to one real change

Start with the engineering change course and use one small repair to follow the task contract, candidate commit, CI, runtime evidence, and recovery:

  1. Define expected behavior and the scope that must remain unchanged.
  2. Identify existing edits and arrange branches and working directories.
  3. Choose changes with the index and inspect the diff.
  4. Record and verify a specific commit and assess test coverage.
  5. Make a review decision and identify the actual release revision.
  6. Explain the boundary between code recovery and business compensation.

Continue with Accept an Agent Change, CI for AI-Generated Changes, the review example, commit splitting, and AI Agent Incident Recovery.

Use this question to check your explanation: when an agent says “finished,” can you identify the commit scope, evidence, and what remains unverified?

Part three: turn judgment into team mechanisms

Choose for your constraints; a team does not need every workflow at once.

Constraint Reading Decision to make
Shared collaboration conventions Team Workflows Integration frequency, branch lifetime, and ownership
Background or parallel agents increase integration pressure Background Agent Tasks → Multi-Agent Strategy How each result is reclaimed, and how isolated results are compared, tested, and integrated
Changes depend on each other Stacked PR Whether downstream evidence survives an upstream change
Acceptance requires enforceable rules GitHub Governance Which permissions, checks, and approvals actually apply
Releases cause external effects Release Management How commits, artifacts, environments, and outcomes correspond

Then read two AI Agent engineering cases and company case studies to compare sources, constraints, and tradeoffs. Public reports offer experience; a team still judges fit from its own repository and validation results.

References to use as needed