i

Description

Vue aérienne d’une petite rivière qui se jette dans un grand fleuve entre des rives boisées.

Source

Wikideas1 · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Git in Depth

Understand Git's object model (blob, tree, commit, tag), the index, references, and reflog: that's what makes commands predictable.

In brief

• Understand Git's object model (blob, tree, commit, tag), the index, references, and reflog: that's what makes commands predictable.
• Choose between merge, rebase, cherry-pick, revert, reset by understanding their effects on history.
• Find a defect with bisect, recover “lost” work with reflog.
• Manage large files and large repositories (LFS, partial/shallow clone, sparse-checkout), secrets, and signing.
• Know where Git on Azure DevOps, GitHub, and GitLab differs, and what AI brings (and does not replace).

On this page

1. The basics in ten commands
2. The object model
3. The index and the three areas
4. References, HEAD, and reflog
5. Merging with merge, rebase, cherry-pick, revert
6. Undo with reset, restore, revert
7. Find with log, blame, bisect, pickaxe
8. Hooks
9. Submodules, subtrees, LFS
10. Large repositories, partial, shallow, sparse, monorepo
11. Signing commits and tags
12. Secret management
13. Expert commands
14. Classic pitfalls
15. Git on Azure DevOps, GitHub, and GitLab
16. AI contribution
17. See also

Level: 🟢→🔴

The basics in ten commands#

🟢 Novice level

git clone <url>              # copy a repository (full history)
git status                   # where am I?
git switch -c feature/kpi    # create and switch to a branch
git add chemin/fichier.sql   # stage (index) a change
git commit -m "Message"      # save locally
git fetch                    # retrieve remote WITHOUT touching my work
git pull --rebase            # fetch + replay my commits on top
git push -u origin feature/kpi   # publish the branch
git log --oneline --graph --decorate   # read history
git diff / git diff --staged # see what changed (unstaged / staged)

Beginner's golden rule: git status before anything else, git fetch rather than git pull when in doubt, never rewrite a shared branch.

The object model#

🟡 Practical level

Everything is stored in .git/objects, by hash identifier (principle). Four object types:

commit C3 ──► root tree ──► blob  README.md
   │                    └──► tree  Datamart/ ──► blob 010_Core.sql
   └─parent─► commit C2 ──► ...

Check for yourself:

git cat-file -t HEAD         # commit
git cat-file -p HEAD         # displays tree, parent, author, message
git cat-file -p HEAD^{tree}  # contents of root folder
git ls-tree -r HEAD --name-only | head

A branch is just a 41-byte file containing a commit identifier (.git/refs/heads/main). So creating a branch is instant and free. A commit knows its parents, never its children: history is a directed acyclic graph (DAG).

Physical storage: “loose” objects (zlib), then grouped into packfiles with delta compression (git gc). A repository may seem large in history but compact after gc.

The index and the three areas#

🟡 Practical level

Git manipulates three areas:

 Working directory  --git add-->  Index (staging area)  --git commit-->  Repository
        ▲                                   │                                         │
        └────────── git restore ◄───────────┘          git restore --staged ◄─────────┘

The index is a list of what the next commit will be. Benefit: compose clean commits. git add -p stages by chunks (hunks); git restore --staged unstages; git stash sets aside the working state (equivalent to a lightweight shelveset, see 03).

git add -p script.sql        # choose hunk by hunk
git commit -v                # view diff in message editor
git commit --fixup <sha>     # prepare a fix to integrate
git rebase -i --autosquash origin/main

References, HEAD, and reflog#

🟡 Practical level

• References: refs/heads/* (local branches), refs/remotes/origin/* (remote tracking), refs/tags/*.
• HEAD: the current position; normally a symbolic reference to a branch. Detached HEAD: HEAD points directly to a commit (after git checkout <sha> or a tag). Commits created then are attached to no branch: create one (git switch -c rescue) before leaving.
• Relative notation: HEAD~2 (two “first” parents back), HEAD^2 (second parent of a merge), main@{yesterday}, :/text (commit whose message contains “text”).

Reflog is the local journal of HEAD and branch movements. It saves you: a failed reset --hard or rebase doesn't destroy commits, they simply become unreachable by a branch and remain recoverable for about 90 days by default (30 days for unreachable ones, orders of magnitude for default gc.reflogExpire configuration).

git reflog                       # HEAD journal
git reset --hard HEAD@{3}        # return to state from three moves ago
git branch rescue <sha>          # reattach a recovered commit
git fsck --lost-found            # orphan objects

Merging with merge, rebase, cherry-pick, revert#

🟡 Practical level

Three-way merge: Git finds the common ancestor, compares each branch to it, and combines. Default strategy ort (replacement for recursive, verify by version). A conflict occurs when both sides modify the same area.

git merge feature/kpi
# conflict:
git status                  # "both modified"
git diff --name-only --diff-filter=U
# edit markers <<<<<<< ======= >>>>>>>
git add fichier && git merge --continue
git merge --abort           # give up
git config --global merge.conflictStyle zdiff3   # also shows common base
git config --global rerere.enabled true          # remembers resolutions

Cherry-pick a fix to a release branch:

git switch release/9.1
git cherry-pick -x abc1234     # -x adds "(cherry picked from ...)": traceability

Undo with reset, restore, revert#

🟡 Practical level

Find with log, blame, bisect, pickaxe#

🟡 Practical level

git log --oneline --graph --all --decorate -20
git log -- chemin/script.sql                  # history of a file
git log --follow -p -- chemin/script.sql      # follow across renames
git log -S"DateExploitation" --oneline        # pickaxe: commits that add/remove the string
git log -G"regex" -p                          # same by regular expression
git log --since="2026-09-01" --author="name" --stat
git blame -w -C -L 120,160 script.sql         # -w ignores spaces, -C follows copies
git shortlog -sn --no-merges                  # contribution by author

git bisect automates binary search for the faulty commit: you mark a “bad” commit and a “good” one, Git proposes a midpoint, you test, and so on in O(log n).

git bisect start
git bisect bad HEAD
git bisect good v9.0.0
# Git checks out a commit: test then tell it
git bisect good     # or git bisect bad
# or automate:
git bisect run powershell -File tests/Test-Datamart.ps1
git bisect reset

Hooks#

🟡 Practical level

Hooks are scripts in .git/hooks (not versioned). To share them: git config core.hooksPath .githooks and version the folder, or use a manager (pre-commit, Husky, lefthook).

#!/bin/sh
# .githooks/commit-msg: requires a ticket reference
grep -Eq '^(#[0-9]+|AB#[0-9]+) ' "$1" || { echo "Message: prefix with AB#<work item no.>"; exit 1; }

Submodules, subtrees, LFS#

🟡 Practical level

Submodule (git submodule): a Git repository inside another, pinned to a specific commit. Useful for sharing a library (a shared SQL toolbox) across repositories. Cost: --recurse-submodules clone, explicit updates, frequent confusion.

Subtree (git subtree): copies a repository's history into a subfolder; no special command for consumers, but heavier history.

Git LFS (Large File Storage) replaces large files with small pointers in history; content is stored elsewhere.

git lfs install
git lfs track "*.pbix" "*.bak" "*.zip"
git add .gitattributes
git lfs ls-files
git lfs migrate import --include="*.pbix" --everything   # rewrites history!

Large repositories, partial, shallow, sparse, monorepo#

🔴 Expert level

git clone --filter=blob:none --sparse https://.../mon-produit.git
cd mon-produit
git sparse-checkout set Datamart/Datamart Reports

Monorepo or multi-repo? The monorepo (one repo, multiple products/modules) brings: cross-cutting atomic changes (one commit modifies SQL and report), a single history, one toolchain. Cost: size, non-granular permissions, builds to make incremental. Multi-repo brings: independent permissions and cycles; cost: version coordination, synchronization, “dependency hell.”

Context: team of 5 to 30 people, a few GB of content.

Signing commits and tags#

🔴 Expert level

The author of a commit is a simple string (user.name): it can be spoofed. Cryptographic signing proves the signer's identity.

git config --global gpg.format ssh                # sign with SSH key (Git ≥ 2.34)
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true
git log --show-signature -1
git tag -s v9.1.0 -m "Release 9.1.0"
git verify-tag v9.1.0

Choices: GPG (legacy, keyring management), SSH (simpler, already present), S/MIME (enterprise certificates). Platforms show a “verified” badge; for a real audit requirement, enforce signing through branch policy (platform-dependent, verify). Don't confuse: signature = identity; content integrity = hashing.

Secret management#

🔴 Expert level

A committed secret (SQL password, connection string, token, API key) is compromised even after deletion: it remains in history, forks, and clones.

Defense hierarchy:

1. Don't write it: use variables, a vault (Azure Key Vault), integrated auth/managed identity instead of passwords.
2. Prevent commit: .gitignore (*.local.*, *.pfx, appsettings.*.json files), pre-commit hook with a detector (gitleaks, detect-secrets).
3. Detect server-side: platform secret scanning (GitHub secret scanning/push protection, GitHub Advanced Security for Azure DevOps, also offered as separate products Secret Protection and Code Security, limited to Azure DevOps Services — license to verify).
4. If leaked: revoke and rotate immediately (rewriting history is never enough), then clean with git filter-repo (recommended tool replacing filter-branch) or BFG, then force-push rewritten history and have the team re-clone.

git filter-repo --path secrets.json --invert-paths   # removes a file from all history

Expert commands#

🔴 Expert level

git worktree add ../hotfix release/9.0     # multiple directories, one single repository
git stash push -m "wip" -- chemin/         # partial stash
git restore -SW --source=release/9.0 -- fichier
git diff --stat main...feature             # three dots: from common ancestor
git log main..feature                      # two dots: what feature has extra
git log --left-right --cherry-pick main...feature   # see "equivalent" commits
git cherry -v main feature                 # commits not yet applied (by patch-id)
git rev-list --count A..B
git reflog expire --expire=now --all && git gc --prune=now   # purge (irreversible)
git update-index --assume-unchanged fichier  # avoid: hides, does not protect
git notes add -m "Acceptance tested" <sha>      # annotation outside commit
git archive --format=zip HEAD -o kit.zip     # clean export of a state (without .git)
git describe --tags                          # v9.1.0-14-gabc1234
git maintenance start
git config --global alias.lg "log --oneline --graph --decorate --all"

git worktree is the BI expert's weapon when maintaining multiple product versions: one directory per version (see 05), a single repository, no destructive branch switching.

git describe generates a readable version number from the latest tag: useful for timestamping a kit (kit-9.1.0-14-gabc1234).

Classic pitfalls#

🔴 Expert level

Git on Azure DevOps, GitHub, and GitLab#

🔴 Expert level

Notable specifics:

• Azure Repos: in the same project, you can have multiple Git repositories and one TFVC repository (03). Branch policies (reviewers, builds, work item linking) cover much of what check-in policies did in TFVC. More details in Azure DevOps Server (ex-TFS) in Depth.
• GitHub: richest ecosystem (Actions, Dependabot, code scanning, Codespaces). Rulesets complement branch protection rules (both coexist and their rules stack; multiple rulesets can apply to the same branch).
• GitLab: integrated DevOps platform, a good choice if you want everything in one self-hostable tool.
• In all cases: protect main, require PR + build, forbid force-push, tag releases, back up the repository.

Ratings /5 (context: team of 10 to 30 people, release cycles by version, Microsoft ecosystem already in place):

AI contribution#

Prompt examples:

Here is the staged diff (git diff --staged). Propose a commit message in French:
title ≤ 72 characters in the imperative, body explaining why, without inventing
a ticket. If the diff mixes multiple topics, say so and propose how to split it.

Here is the output of git log --oneline v9.0.0..v9.1.0 -- Datamart/.
Group by theme (bug fix, enhancement, technical) and draft release
notes for a functional consultant. Flag ambiguous entries instead of guessing.

AI does not replace: judgment about what should be committed, responsibility for the merge, business acceptance testing of the numbers, or the discipline of atomic commits (AI on a catch-all commit produces a catch-all message). See AI in Planning and Version Control Tools and the Cross-Functional Summary — AI Contribution.

See also#

• Overview of Version Control Systems · TFVC in Depth · Git vs TFVC: compare, migrate, coexist
• Branching Strategies · VCS and SQL / BI data
• CI/CD · Matrix: version control and branches
• Glossary · Rating

✻ Written by Claude Sonnet 5.5