Module 14 — Ignoring, Attributes, and Big Files
Updated 7 September 2026
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
Part A — .gitignore: keeping files out
A1. Patterns, and what they match
.gitignore is a file listing patterns for paths Git should not track — build output, logs, dependency directories, local secrets, editor droppings. Once a path matches, Git stops offering it in git status and won't stage it with git add .. The pattern rules: a bare name or glob (*.log, secret.key) matches anywhere; a trailing slash (build/) matches directories; a leading slash (/config.local) anchors to the repo root; and a leading ! re-includes something a previous pattern excluded (*.log then !keep.log). .gitignore files are themselves committed and can sit in any directory (applying to that subtree), so the ignore rules travel with the repo — everyone on the team ignores the same clutter automatically.
🧪 Exercise 14.1 — ignore clutter, watch status go quiet
mkdir -p ~/git-course && cd ~/git-course
git init -q kitchen && cd kitchen
echo "app code" > app.py && git add app.py && git commit -q -m "Add app"
mkdir -p logs build
echo "run log" > logs/app.log
echo "artifact" > build/out.o
echo "secret=123" > .env
git status -s # clutter everywhere
cat > .gitignore <<'EOF'
# ignore logs and build output
*.log
build/
.env
EOF
git status -s # ...silenced✅ Expected result — click to reveal
?? .env
?? build/
?? logs/
?? .gitignoreWhat to read out of it: the first git status -s (top of the output) listed .env, build/, and logs/ as untracked clutter. After writing .gitignore, the second status shows only ?? .gitignore — the log, build directory, and secret vanished from Git's view: they still exist on disk, but Git now pretends not to see them, so a careless git add . can't sweep them in. The .gitignore file itself is untracked (you'll commit it — ignore rules belong in history so the whole team shares them). This is the single most important habit for keeping secrets and junk out of a repository: ignore before the first git add ., not after.
A2. The already-tracked trap
Here is the trap that catches everyone once: .gitignore only affects untracked files. If a file is already tracked (you committed it before ignoring it), adding it to .gitignore does nothing — Git keeps tracking it, keeps showing its changes, keeps committing them. The fix is Module 2's git rm --cached <file>: stop tracking it (remove from the index) while keeping it on disk, then commit that removal. From that commit forward, the .gitignore rule takes over. And git check-ignore -v <path> is the debugger for "why is (or isn't) this ignored?" — it names the exact .gitignore file and line that decides.
🧪 Exercise 14.2 — the trap, and the escape
cd ~/git-course/kitchen
git add .gitignore && git commit -q -m "Add gitignore"
echo "config data" > config.cache
git add config.cache && git commit -q -m "Add config.cache" # oops, committed it
echo "*.cache" >> .gitignore # now try to ignore it...
git status -s # ...gitignore did NOT untrack it
git rm --cached config.cache # the real fix
git status -s
git commit -q -am "Stop tracking config.cache"
git check-ignore -v config.cache # now Git confirms it's ignored
ls config.cache # still on disk✅ Expected result — click to reveal
M .gitignore
rm 'config.cache'
M .gitignore
D config.cache
.gitignore:5:*.cache config.cache
config.cacheWhat to read out of it: after adding *.cache to .gitignore, git status -s shows only M .gitignore — config.cache is not listed as untracked or ignored, because it's still tracked; the ignore rule was silently powerless. git rm --cached then stages its removal (D config.cache) while leaving the file on disk (ls still finds it). After that commit, git check-ignore -v config.cache finally reports a match (.gitignore:5:*.cache) — proof the ignore now applies. The lesson interviewers probe: ignoring a file you already committed is a two-step operation, and forgetting rm --cached is why "I added it to gitignore but Git still tracks it" is one of the most common Git confusions. (Note: while a file is still tracked, check-ignore reports nothing for it — the tool considers tracked paths not-ignored; the match only appears once it's untracked.)
.gitignore is a sticky note on your inbox: "don't file anything matching these — junk mail, drafts, sticky notes themselves." New matching papers get skipped automatically. It keeps your filing cabinet (the repo) full of only real documents.
Where the analogy stops working. The note governs incoming papers only — it has zero power over documents already filed. Slap "don't file bank statements" on your inbox and the twelve statements already in the cabinet stay filed until you physically pull them (git rm --cached). And pulling today's copy doesn't erase the photocopies in last year's archive boxes (old commits) — which, for a leaked secret, is the whole problem. The note prevents; it does not un-file, and it certainly does not shred the archive.
🎯 Interview questions — Part A
🎯 "What is the purpose of the .gitignore file?" — asked verbatim in Interview Coder (Sep 2025) and GeeksforGeeks (updated Jul 2026)
.gitignore lists path patterns Git should not track — build artifacts, logs, dependency folders (node_modules/), local config, and secrets — so git status stays clean and git add . can't accidentally stage clutter. Patterns support globs (*.log), directory (build/) and root-anchored (/x) forms, and negation (!keep.this). The files are committed, so ignore rules are shared by the whole team; they can live per-directory. Crucially, .gitignore affects only untracked files — an already-committed file must be untracked with git rm --cached before the rule applies.
The details that separate candidates: an average answer says "lists files Git ignores." A strong answer states the untracked-only rule and the git rm --cached fix, warns that ignoring a committed secret does not remove it from history (rotate + filter-repo), and knows the debugging tool git check-ignore -v. Mentioning global ignores (core.excludesFile for editor/OS junk that shouldn't be in every project's .gitignore) and ! negation rounds out real fluency.
🎯 "How do you remove tracking but keep the file locally?" — asked verbatim in Interview Coder, Sep 2025; also as "How does Git handle file deletion?" in GeeksforGeeks (updated Jul 2026)
git rm --cached <file> — it removes the file from the index (Git stops tracking it) while leaving it untouched on disk, unlike plain git rm which deletes it from both. Commit the removal, and from that point Git no longer versions the file; pair it with a .gitignore entry so it doesn't get re-added. The canonical uses: a file that was committed before it should have been ignored (a config, a cache, an accidentally-committed secret), and stopping tracking of a now-generated file.
The details that separate candidates: an average answer gives the command. A strong answer contrasts it with git rm (both vs disk-only), pairs it with the .gitignore follow-up, -r for directories, and states the hard truth for secrets: --cached stops future tracking but the value remains in every historical commit — rotate it and, if required, rewrite history. That last point is the difference between "stopped tracking" and "actually removed the leak."
Part B — .gitattributes: line endings and diffs
B1. Ending the CRLF wars
Windows ends text lines with CRLF (\r\n); Linux and macOS use LF (\n). On a mixed team this causes phantom diffs — a file looks "entirely changed" because someone's editor rewrote every line ending, drowning the real one-line change. .gitattributes fixes this by declaring, per file pattern, how Git should handle content. * text=auto tells Git to normalize text files to LF in the repository and convert to the platform's convention on checkout; *.csv text eol=lf forces LF for specific types; *.png binary marks files Git should never touch or try to diff. Like .gitignore, it's committed, so the whole team gets consistent handling. git check-attr -a <file> shows which attributes apply to a path.
🧪 Exercise 14.3 — normalize a CRLF file to LF in the repo
cd ~/git-course/kitchen
printf 'name,qty\r\nflour,500\r\n' > data.csv # a CRLF (Windows) file
cat > .gitattributes <<'EOF'
* text=auto
*.csv text eol=lf
*.png binary
EOF
git add .gitattributes data.csv # note the warning Git prints
git commit -q -m "Add attributes and CRLF data"
git check-attr -a data.csv # which attributes apply?
git show HEAD:data.csv | cat -A | head -2 # what got STORED — LF or CRLF?✅ Expected result — click to reveal
warning: in the working copy of 'data.csv', CRLF will be replaced by LF the next time Git touches it
data.csv: text: set
data.csv: eol: lf
git show output:
name,qty$
flour,500$What to read out of it: git add printed a warning that it will normalize CRLF to LF — Git is telling you it's about to standardize the line endings per your attributes. git check-attr -a confirms the rules applying to data.csv: text: set and eol: lf. The payoff is the last command: git show HEAD:data.csv | cat -A reveals what's stored in the repository — each line ends in $ (LF) with no ^M (which is how cat -A shows CR). So the file went in with Windows CRLF, but the committed blob is clean LF — every platform now checks out consistent content, and the "whole file changed" phantom diffs stop. The repository holds one canonical form; each OS gets its native form on checkout.
🎯 Interview questions — Part B
🎯 Corpus note — .gitattributes and line endings
Neither .gitattributes nor core.autocrlf appears as a verbatim standalone question in the surveyed corpus (Interview Coder, GeeksforGeeks) — both surface only inside broader answers (often the LFS question, since LFS uses .gitattributes) — so this Part carries a corpus note rather than a fabricated block. The interview-ready substance: .gitattributes declares per-pattern handling (line-ending normalization via text/eol, binary to skip diffing, plus diff/merge drivers and the LFS filter), it's committed so it's shared, and it's the authoritative line-ending fix versus the per-machine core.autocrlf config that drifts across a team. The signal is knowing why committed attributes beat per-developer config — the same "shared, portable, in-the-repo" theme as .gitignore.
Part C — Git LFS: large files done right
C1. Pointers instead of blobs
Module 3 warned it: Git stores a whole new blob for every version of every file, and binaries don't delta-compress — so committing a 50 MB design file ten times bloats the repo by ~500 MB forever (immutable history). Git LFS (Large File Storage) solves this. For file patterns you designate, LFS commits a tiny pointer file (a few lines: a hash and size) into Git history, while the actual bytes are stored separately — in .git/lfs locally and on an LFS server remotely. History stays small and fast; the big files are fetched on demand. Setup is git lfs install (once), then git lfs track "<pattern>" — which writes an LFS filter into .gitattributes (Part B's file, now doing storage work). From then on, matching files are transparently swapped for pointers on commit and restored on checkout.
🧪 Exercise 14.4 — commit a binary through LFS and see the pointer
cd ~/git-course && git init -q lfsdemo && cd lfsdemo
git lfs install --local
git lfs track "*.psd" # designate the pattern
cat .gitattributes # LFS wrote a filter line
head -c 5000 /dev/urandom > design.psd # a stand-in "large binary"
git add .gitattributes design.psd
git commit -q -m "Add design via LFS"
git show HEAD:design.psd # what's in HISTORY — bytes or pointer?
git lfs ls-files # which files LFS manages
find .git/lfs -type f # where the real bytes live✅ Expected result — click to reveal
*.psd filter=lfs diff=lfs merge=lfs -text
version https://git-lfs.github.com/spec/v1
oid sha256:371eb4911d29f2d6500dab859fbedf5264d4ce8216c741f34efc9c48cf17d3b7
size 5000
371eb4911d * design.psd
.git/lfs/objects/37/1e/371eb4911d29...What to read out of it: git lfs track wrote *.psd filter=lfs diff=lfs merge=lfs -text into .gitattributes — that filter is what intercepts these files. The revealing command is git show HEAD:design.psd: what's stored in Git history is not the 5000 random bytes but a three-line pointer — a spec URL, the content hash (oid sha256:…), and the size. The real bytes sit in .git/lfs/objects/… (and would be pushed to an LFS server, not the Git remote). git lfs ls-files confirms LFS manages design.psd. So the repo's history carries a few dozen bytes per version instead of the full file — Module 3's bloat problem, dissolved: version a huge asset 100 times and history grows by 100 tiny pointers, not 100 full copies.
🎯 Interview questions — Part C
🎯 "How do you handle large files with Git?" — asked verbatim in Interview Coder (Sep 2025) and GeeksforGeeks (updated Jul 2026)
Git LFS (Large File Storage). You git lfs track "<pattern>" (which registers a filter in .gitattributes), and thereafter Git commits a small text pointer — a content hash and size — into history while the actual bytes are stored out-of-band (in .git/lfs locally, on an LFS server remotely) and fetched on demand. This keeps history small and clones fast even for repos full of large binaries, solving Git's core weakness: it stores a full new blob per version and binaries don't delta-compress, so versioned large files bloat history permanently. Key discipline: track before the first commit of the file.
The details that separate candidates: an average answer says "use Git LFS." A strong answer explains the pointer mechanism and why it's needed (Git's per-version-full-blob storage + no binary delta compression), notes that tracking must precede the commit (a file committed without LFS is already bloating history and needs a history rewrite to remove), and mentions the operational tail: LFS needs server support/quota, and git lfs ls-files/lazy fetch for large-repo workflows. Naming the alternative for the follow-up "without LFS?" — external artifact stores/package registries with the repo holding only references — shows range.
🎯 "How do you manage large binary files in Git without using Git LFS?" — asked verbatim in GeeksforGeeks' 70+ Git Interview Questions, updated Jul 2026
Keep the binaries out of Git and store references instead. Practical approaches: an artifact repository or package registry (Artifactory, Nexus, npm/PyPI, a container registry) holding the binaries, with Git committing only a version/URL/checksum the build resolves; cloud object storage (S3/GCS) addressed by a manifest in the repo; or a package/dependency manager that pulls the assets at build time. The repo stays a lightweight source-of-truth of code plus pointers, and the heavy bytes live where large-object storage is cheap and versioned. Alternatives inside the Git family include git-annex (LFS's conceptual predecessor) for pointer-style management without the LFS service.
The details that separate candidates: an average answer just names one store. A strong answer frames the principle — Git is for text/source; large or opaque binaries belong in systems built for them, with Git holding references — and matches the tool to the case (registry for build outputs, object storage + manifest for datasets, package manager for third-party assets). Noting git-annex and the checksum-in-repo pattern (so the reference is verifiable) demonstrates depth beyond "just use S3."
Part D — Submodules: a repo inside a repo
D1. Embedding a pinned dependency
Sometimes you need another Git repository inside yours — a shared library, a vendored dependency — pinned to a specific commit rather than merged in. A submodule does exactly that: git submodule add <url> <path> clones the other repo into a subdirectory and records, in your repo, a pointer to one exact commit of it (plus a .gitmodules file mapping path → URL). Your repo doesn't store the submodule's files or history — it stores a gitlink: a special entry naming the commit the submodule should be at. That pinning is the point: the parent repo controls which version of the dependency it uses, and updating is a deliberate act (move the pointer, commit), not an automatic drift. The tradeoff is friction, which the exercise and trap make concrete.
🧪 Exercise 14.5 — add a submodule, inspect the gitlink
This uses local repos so it runs offline; real submodules use remote URLs. The -c protocol.file.allow=always flag is only needed for local-path submodules (a security default).
cd ~/git-course
git init --bare -q shared-lib.git # a stand-in "shared library" remote
git clone -q shared-lib.git shared-seed && cd shared-seed
echo "shared utility v1" > util.sh && git add util.sh && git commit -q -m "Add shared util"
git push -q origin main
cd ~/git-course/kitchen
git -c protocol.file.allow=always submodule add ../shared-lib.git libs/shared
cat .gitmodules # the path -> URL mapping
git ls-files -s libs/shared # the GITLINK (mode 160000)
git commit -q -m "Add shared library as submodule"✅ Expected result — click to reveal
[submodule "libs/shared"]
path = libs/shared
url = ../shared-lib.git
160000 41025d8372e5d74fa30bb706864686891f218814 0 libs/sharedWhat to read out of it: .gitmodules records the mapping — path libs/shared ← URL ../shared-lib.git — and this file is committed, so anyone cloning knows where to get the submodule. The revealing line is git ls-files -s: the entry for libs/shared has mode 160000 — the special gitlink mode (not 100644 for a file or 040000 for a tree; Module 3's tree entries, now with a fourth kind). It names a single commit (41025d8…) of the other repository. Your repo stores that 40-character pointer, not the library's files — so the parent is pinned to exactly commit 41025d8 of the shared lib until someone deliberately moves the pointer. That pin is the submodule's whole reason to exist.
D2. The clone-and-update friction
Submodules' pinning comes with a famous cost: cloning a repo does not fetch its submodules' contents by default. A fresh clone gets the gitlink and .gitmodules but leaves submodule directories empty until you run git submodule update --init (or clone with --recurse-submodules). Forgetting this is the #1 submodule confusion — "the library folder is empty and the build fails." And this friction repeats: pulling parent changes doesn't auto-update submodules, updating a submodule is a two-repo commit dance, and every teammate must remember the --recurse flags. The friction is real enough that many teams prefer package managers or subtrees for shared code, reserving submodules for cases where exact-commit pinning of a separate repo is genuinely required.
🧪 Exercise 14.6 — clone, find the empty dir, then populate it
cd ~/git-course
git -c protocol.file.allow=always clone -q kitchen kitchen-clone
cd kitchen-clone
ls libs/shared # empty! the trap
git submodule status # note the leading '-' (not initialized)
git -c protocol.file.allow=always submodule update --init
cat libs/shared/util.sh # now the content is there
git submodule status # '-' is gone✅ Expected result — click to reveal (the first ls shows an empty dir on purpose)
-41025d8372e5d74fa30bb706864686891f218814 libs/shared
Submodule path 'libs/shared': checked out '41025d8372e5d74fa30bb706864686891f218814'
shared utility v1
41025d8372e5d74fa30bb706864686891f218814 libs/shared (heads/main)What to read out of it: right after cloning, ls libs/shared prints nothing — the directory exists but is empty, the classic "why is my dependency missing?" moment. git submodule status shows the commit with a leading -, meaning "not initialized." After git submodule update --init, Git clones the submodule at exactly the pinned commit (checked out '41025d8…') and the file appears (shared utility v1); status now shows the same hash with no - (and (heads/main)), meaning populated and healthy. The takeaway: a repo with submodules needs --recurse-submodules on clone (or submodule update --init after) — bake it into your setup docs, because the empty-directory trap catches every newcomer exactly once.
🎯 Interview questions — Part D
🎯 "What is the use of git submodule?" — asked verbatim in Interview Coder (Sep 2025); also "What is a Git submodule?" in GeeksforGeeks (updated Jul 2026)
A submodule embeds another Git repository inside yours at a subdirectory, pinned to one specific commit. Your repo stores a gitlink (mode 160000 — a pointer to that exact commit) plus a committed .gitmodules file mapping the path to the submodule's URL; it does not store the submodule's files or history. Use it when you need a fixed, deliberately-updated snapshot of a separate repo — a shared library or vendored dependency — with the parent controlling exactly which version it uses. Add with git submodule add <url> <path>; clone consumers need --recurse-submodules (or git submodule update --init) to actually populate it.
The details that separate candidates: an average answer says "a repo inside a repo." A strong answer states the pinning-to-a-commit purpose (that's why you'd choose it over a plain copy), the gitlink mechanism, and the real friction — clones don't fetch submodule content by default, updates are a two-repo dance — which is why teams often prefer package managers or subtrees unless exact-commit pinning of a separate repo is essential. Knowing when not to use submodules is as valuable as knowing how.
Part E — Production practice
E1. Symptom → cause → diagnosis → fix
| Symptom | What is really happening | What to run | The fix |
|---|---|---|---|
| "I added it to .gitignore but Git still tracks it" | .gitignore affects untracked files only; this one's already tracked | git check-ignore -v <file> (reports nothing while tracked) | git rm --cached <file> then commit; the rule applies from then on |
| A secret got committed; adding it to .gitignore "removed" it | It's gone from the working tree's tracking but remains in all history | git log -p -- <file> (still shows the value in old commits) | Rotate the secret NOW; scrub history with git filter-repo (Module 15) + force-push if required |
| A file shows as "entirely changed" though you edited one line | Line endings were rewritten (CRLF↔LF) by an editor or a teammate's config | git diff (whole file red/green) · git check-attr -a <file> | Commit a .gitattributes with • text=auto; renormalize (git add --renormalize .) |
| Line endings inconsistent despite "everyone set autocrlf" | core.autocrlf is per-machine config — it drifts across the team | Ask three teammates for git config core.autocrlf (three answers) | Move policy into committed .gitattributes — shared by construction |
| Repo is huge and clones take forever | Large binaries were committed directly (no LFS) — full blob per version, no delta | Find big objects (Module 15's rev-list tricks) · git lfs ls-files | Adopt LFS going forward; migrate existing blobs with git lfs migrate • history rewrite |
| Cloned a repo, a dependency folder is empty, build fails | Submodule content isn't fetched on a plain clone | git submodule status (leading - = not initialized) | git submodule update --init (or re-clone with --recurse-submodules) |
| Teammate's "submodule update" shows a modified submodule you didn't change | Someone committed the submodule at a new pinned commit; yours is at the old one | git diff (shows the gitlink hash changing) · git submodule status | git submodule update to move to the pinned commit; commit if you intend the bump |
E2. Capstone — four tickets
Worked answer: committed .gitignore (or several, per-subtree) as the shared baseline — start from a language-appropriate template (gitignore.io / GitHub's templates) covering __pycache__/, node_modules/, .terraform/, build output, and OS/editor junk, plus explicit secret patterns (.env, *.pem, *.tfvars). Layer a global ignore (git config --global core.excludesFile ~/.gitignore_global) for personal editor/OS files (.DS_Store, .idea/) so they don't clutter every project's committed ignore. Enforce that secrets can't slip in before the first commit: a pre-commit hook (Module 15) or CI scan (gitleaks, git-secrets) that rejects commits containing key patterns — because .gitignore only helps if the file matches a rule and nobody git add -f's past it. State the non-negotiable: ignore secrets before the first commit, because after is a rotate-and-rewrite incident (Ticket in Part A's trap). One baseline .gitignore, one global ignore, one automated guard.
Worked answer: classic CRLF↔LF churn — editors on different OSes rewrite line endings, and (the root cause) the team relied on per-machine core.autocrlf, which drifts. Permanent fix: commit a .gitattributes with * text=auto (normalize all text to LF in the repo, native on checkout) plus explicit rules for known types (*.sh text eol=lf, *.bat text eol=crlf, *.png binary). Then renormalize the existing repo once: git add --renormalize . and commit — this rewrites the stored blobs to canonical LF in a single, reviewable "normalize line endings" commit, after which diffs are clean. Communicate the one-time noisy commit so it's not mistaken for a real change, and ideally merge it when no long-lived branches are open (to minimize conflicts). The lasting lesson for the team: line-ending policy belongs in committed .gitattributes, never in each developer's config.
Worked answer: two phases — stop the bleeding, then (carefully) clean the wound. Prevent going forward: git lfs install, git lfs track "*.ckpt" "*.psd" "*.bin" (writes .gitattributes), so all future large-file commits become pointers — history stops growing. For the existing bloat, the honest options: git lfs migrate import --include="*.ckpt,*.psd" rewrites history to move past large files into LFS — but this is a history rewrite (new hashes for every affected commit, Module 10's golden rule at repo scale): it requires coordinating a force-push, everyone re-cloning, and accepting that old commit hashes change; schedule it as an announced migration, not a quiet fix. Alternatively, if the binaries don't need versioning at all, move them out of Git entirely into object storage / an artifact registry (Part C's no-LFS answer) with the repo holding only references. Set up quota/monitoring on the LFS store and a CI check rejecting non-LFS large files (git lfs pre-push hook). The framing: this is expensive precisely because the policy wasn't set before the first big commit — the whole ticket is a lesson in getting LFS/ignore rules right on day one.
Worked answer: decide by how the dependency is consumed, and lean against submodules unless exact-commit pinning of a live repo is essential. Submodule fits if all three services must pin an exact commit of the auth repo, coordinate lock-step, and you accept the friction (every clone needs --recurse-submodules, updates are a two-repo dance, newcomers hit the empty-directory trap). Package manager (publish the auth library as a versioned internal package — npm/PyPI/Maven/Go module) is usually better: consumers pin a semver range (Module 12), updates are a one-line version bump, tooling handles fetching, and there's no submodule friction — this is the default recommendation for shared code. Subtree is the middle path if you want the library's files vendored directly into each repo without the submodule ceremony, at the cost of a more complex update flow. Recommend the package-manager route unless a concrete requirement (e.g. the services build the auth code from source in lock-step, or it's not publishable) forces submodules. The interview close: submodules solve exact-commit pinning of a separate repo, but most "shared library" needs are better served by versioned packages — knowing when not to reach for submodules is the senior signal.
E3. Documentation reference
| Topic | Official source | What it covers |
|---|---|---|
| .gitignore | gitignore manual | Pattern syntax, precedence, negation, per-dir files |
| Ignoring files (tutorial) | Ignoring files — GitHub Docs | Global ignores, templates, common cases |
| .gitattributes | gitattributes manual · Git Book §8.2 | text/eol/binary, diff & merge drivers, filters |
| Git LFS | git-lfs.com | Install, track, pointers, migrate, ls-files |
| Submodules | Git Book §7.11 — Submodules · git-submodule manual | add/update/status, gitlink, --recurse-submodules |
E4. Self-assessment
Answer each aloud, from memory, before moving on. Every one is answered on this page.
- What does .gitignore affect, and — crucially — what does it not affect?
- You committed a file, then added it to .gitignore. Why is it still tracked, and what's the exact fix?
- Why does adding a leaked secret to .gitignore not actually protect it, and what are the two real remediation steps?
- What does git check-ignore -v tell you, and what does it report for an already-tracked file?
- What problem does .gitattributes solve for mixed-OS teams, and which one line addresses most of it?
- Why is .gitattributes the authoritative line-ending fix and core.autocrlf only a fallback?
- What does Git commit into history for an LFS-tracked file, and where do the real bytes live?
- Why must you git lfs track a pattern before committing matching files?
- Give one way to manage large binaries without LFS, and the principle behind it.
- What is a gitlink (mode 160000), and what does a repo store for a submodule?
- Why is a freshly cloned submodule directory empty, and the two commands that fix it?
- When would you choose a package manager over a submodule for shared code, and why?
E5. Sources
🗒️ Cheat sheet — Module 14
| Command / file | What it does |
|---|---|
| .gitignore patterns: *.log · build/ · /root · !keep | Glob anywhere · directory · root-anchored · negate (re-include) |
| git check-ignore -v <path> | Show which .gitignore line decides a path (nothing if it's tracked) |
| git rm --cached <file> · -r <dir> | Stop tracking, keep on disk — the fix for an already-committed file |
| git config --global core.excludesFile ~/.gitignore_global | Personal/OS ignores across all repos (not committed) |
| .gitattributes: • text=auto · *.x text eol=lf · *.png binary | Normalize line endings in-repo · force LF · never diff/touch |
| git check-attr -a <file> · git add --renormalize . | Show attributes applying to a path · re-normalize stored blobs once |
| git lfs install · git lfs track "<pat>" · git lfs ls-files | Enable LFS · designate a pattern (writes .gitattributes) · list LFS files |
| git lfs migrate import --include="<pat>" | Move existing committed blobs into LFS (rewrites history!) |
| git submodule add <url> <path> · cat .gitmodules | Embed a repo pinned to a commit (gitlink 160000) · the path→URL map |
| git clone --recurse-submodules · git submodule update --init | Clone and populate submodules · populate them after a plain clone |
Key concepts: .gitignore keeps untracked files out of Git — it does NOT untrack already-committed files (use git rm --cached), and it does NOT remove a leaked secret from history (rotate + rewrite) · patterns: globs, dir/, /anchored, !negation; check-ignore -v debugs them; global ignores for personal junk · .gitattributes (committed, shared) is the authoritative line-ending fix — * text=auto normalizes to LF in-repo; beats per-machine core.autocrlf · Git LFS commits a small pointer (hash+size) to history and stores real bytes out-of-band — solves binary bloat, but track before the first commit · without LFS, keep binaries in object storage/registries with the repo holding references · a submodule stores a gitlink (mode 160000) pinning one commit of another repo + a .gitmodules map; clones don't fetch its content (needs --recurse-submodules/update --init); prefer package managers for shared code unless exact-commit pinning is essential.