my-git

Roadmap

English 中文

v2.2.0: understanding, experiments, change control, and AI collaboration practices

The handbook explains its purpose through the philosophy and connects paired Chinese and English articles, interactives, and temporary-repository labs for ten topics through the learning path. Existing directories remain a reference index; folder numbers do not dictate reading order. The v2.2.0 release notes define the scope and were prepared on 2026-09-09; GitHub Releases records the publication status.

Merged material

These materials were merged through PR #67; displayed-command fixes and regression coverage were merged through PR #68. Documentation and link CI passed on both PRs. On 2026-09-08, the GitHub Pages build was verified at 42ae30897b09a1b9f8bb147298b0d75204448ddf, and the hosted interactive script matched the corrected revision. This establishes that merged revision only and does not establish reader learning.

Closeout and remaining work

v2.2.0 documentation completion

These items track documentation acceptance for the v2.2.0 scope; merge and deployment status need separate verification.

The historical assessment’s governance, AGENTS.md template, repository conventions, multi-agent and stacked PR operations, incident recovery, CI, background tasks, engineering cases, and tool-article responsibilities are covered. Preserve the original assessment; use these concrete gaps for new work.

Real-reader acceptance tasks

Invite an engineer who did not author the course to start from the knowledge map. The facilitator records predictions, actual actions, the number of hints, and stumbling points without explaining answers first. Run Git commands only in the disposable repositories created by the course labs.

  1. In recovery, predict what happens to C2 and C3 after reflog expiration and cleanup, then run the lab and explain the difference with ref and object checks.
  2. In storage, compare content before and after maintenance, explain what unchanged content establishes, and why it does not establish a performance improvement.
  3. Transfer the model to an Agent scenario involving committed files, unstaged edits, and an external database. Explain which evidence to preserve, what Git can recover, and what needs separate handling.
  4. Navigate from article to interactive and lab, then switch language; record broken links, terminology obstacles, and points needing help.

Record each task as “independent / completed with hints / incomplete,” with differences between prediction and observation. One session establishes only that participant’s behavior on that revision. No participant is scheduled yet; automated checks and Agent-simulated reading do not count as a passing reader session.

Material and evidence boundaries

Code and material visible Scope covered Evidence still needed separately
Ten paired conceptual articles, ten labs, and ten interactive entry points are linked in one order from 01 through 10 Snapshots, objects, index, refs, recovery, merge, rebase, remotes, worktrees, and storage There is no behavior data establishing whether readers can predict, reproduce, and transfer the ideas
The interactive entry keeps the three existing topics for 01 through 03 and adds seven topics for 04 through 10 Every topic can lead from article to interactive and lab; deployment of the merged revision above was verified Browser behavior across all paths, deployment of later fixes, and real reader experience need separate verification
The engineering change course and acceptance loop have a local artifact and HTTP-service exercise Intent, candidate commit, clean-checkout test, artifact, loopback runtime response, and code recovery are observable under a temporary root It does not contact real CI, a hosting platform, production, or an external service, and does not establish supply-chain trust
The command-safety regression rechecks four named old command patterns Stop on a dirty workspace, commit owned paths, reset before partial staging after a soft reset, and substitute the integration branch Other historical examples, remote authorization, branch protection, hooks, and team rules are outside this regression
bash scripts/run-git-learning-labs.sh runs ten course labs, three reading experiments, and three Agent/command regression entry points in sequence Scripted local Git scenarios, including Agent incident recovery, can be rechecked Passing runs do not establish reader learning, performance benchmarks, or production state

Course order and verification

  1. 01 through 03: snapshots, objects, and index. First observe how an edit appears separately in HEAD, the index, and the working tree; then follow the object graph and the next-commit draft.
  2. 04 through 05: references and recovery. Branches, tags, and HEAD precede reachability, reflogs, and GC retention limits.
  3. 06 through 09: history and collaboration. Three-way merge, rebase replay, remote-tracking refs, and worktrees explain divergence, integration, and isolation in order.
  4. 10: storage and maintenance. After the object model, distinguish logical snapshots, packs, GC, and commit-graph. The lab observes only a controlled temporary repository; performance conclusions require separate measurement.
  5. Agent-change acceptance. The local artifact-and-service exercise connects commit, test, and runtime evidence while preserving the boundary that Git cannot automatically reverse external state.

Teaching contract

Each chapter needs a causal question, a stable diagram, one adjustable condition, a temporary-repository lab, expected output, a misconception and recovery boundary, and an agent-oriented judgment exercise. Motion must explain change. Identify whether timing, counters, and hashes are real or illustrative.

Learning is demonstrated through prediction, reproduction, and transfer. Enjoying an animation is useful feedback, but cannot alone establish mastery.

Boundaries to maintain

The goal of v2.0 is to bridge the gap in practical content for modern engineering teams regarding Git / GitHub collaboration, AI programming, incident handling, and engineering governance.

v2.0 Goals

v2.0 aims to accomplish one primary task: establish a clear content structure and complete the first batch of core articles and templates that are ready for immediate use.

Phase 1: 30-Day Version

Week 1: Positioning Upgrade

Week 2: AI Differentiation

Week 3: Team Engineering Practices

Week 4: Incident Playbook and Release

Content Principles

  1. Fewer link piles, more engineering judgment.
  2. Fewer command lists, more scenario explanations.
  3. Less pursuit of exhaustive completeness, more actionable paths.
  4. Every article must answer “When to use this, and when not to.”

v2.0 Release Narrative

AI programming is changing the way software is developed, and the value of Git is evolving accordingly.

v2.0 will systematically add practical Git / GitHub content around team collaboration, GitHub engineering governance, AI code review, incident recovery, and large repository practices.

Recent Optimization Checklist

This site is open source. Improve this page.