Git & GitHub Fundamentals · Module 10 of 12

.gitignore, tags and release references

Keep generated or sensitive files out of normal tracking and mark important commits with durable release references.

Learning objectives

By the end of this module, you should be able to:

Write and test .gitignore rules.
Explain tracked-file behavior versus ignored untracked files.
Create annotated tags for release points.

.gitignore prevents accidental normal tracking

Ignore rules apply primarily to untracked paths. Adding a path to .gitignore does not automatically untrack a file that is already committed. Generated build output, local environment files and editor artifacts are common ignore candidates.

Do not use ignore as secret remediation

If a secret was committed, adding it to .gitignore does not remove it from history. Revoke/rotate the credential first, then follow an approved history-remediation process if required.

Tags name important commits

Annotated tags store tag metadata and are appropriate for release markers. Pushing a branch does not automatically push all tags; publish the specific tag or use an intentional tag-push policy. GitHub Releases can add release notes and assets around Git tags.

Worked examples

See the idea in practice.

Ignore build output and tag a release

printf "dist/\n.env\n" > .gitignore
git add .gitignore
git commit -m "Add ignore rules"
git tag -a v1.0.0 -m "Release v1.0.0"
git show v1.0.0 --no-patch

Ignored untracked paths disappear from normal status output.
The annotated tag resolves to a release commit.

Hands-on lab

Lab — Ignore generated content and tag a clean commit

Goal: Prove ignore behavior, then create and inspect an annotated tag.

Before you start

Git 2.23 or newer is recommended so the labs can use git switch and git restore.
Run labs in a disposable working directory; the included validator creates and removes its own temporary repository.

STEP 1

Create repository

mkdir -p ~/gnu-git-labs/module10 && cd ~/gnu-git-labs/module10
git init -b main
git config user.name "GNU Learner"
git config user.email "learner@example.invalid"

STEP 2

Add ignore rules

printf "dist/\n.env\n" > .gitignore
printf "source\n" > app.txt
mkdir -p dist && printf "generated\n" > dist/app.bin
printf "TOKEN=example-not-real\n" > .env
git status --short

STEP 3

Commit only source and rules

git add .gitignore app.txt
git commit -m "Add source and ignore rules"
git status --short

STEP 4

Create annotated tag

git tag -a v1.0.0 -m "GNU Git lab release"
git tag -n
git show v1.0.0 --no-patch

Verify

dist/ and .env are not staged or committed.
v1.0.0 resolves to the commit.

Expected outcome

The repository has a clean source snapshot plus an annotated release marker.

If it fails

Use git check-ignore -v <path> to see which ignore rule matched.
If an ignored file was already tracked, remove it from the index intentionally; .gitignore alone will not untrack it.

Real-world connection

Build pipelines rely on clean source boundaries and immutable release references to reproduce deployments.

Avoid these traps

Common mistakes

Committing real secrets and assuming .gitignore removes them later.
Using only mutable branch names as release evidence.
Tagging before validating the exact commit being released.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1Does .gitignore untrack an already committed file?

No. It mainly controls discovery/tracking of untracked paths.

2What should happen first if a real secret was committed?

Revoke or rotate the credential; ignore rules are not remediation.

3Why use an annotated tag?

To give an important commit a durable release reference with tag metadata.