Creating Repositories and Recording Changes
Objective. Students initialize a local repository, add files to the staging area, write well-formed commit messages, and inspect repository status and history using git status and git log.
This lesson, its worked examples and its practice questions has not yet been verified by an industry-certified professional or by a certification or approval body. It is a study draft and may contain errors. Do not use it as instructions for work on a job site or on live equipment. Always follow your instructor, your supervising professional, and current official references and regulations.
VoTechWorks program approval and accreditation are still in progress. Credentials are issued only by the certifying bodies named in each program, after their own exams.
What Is a Git Repository?
A repository (repo) is the database Git uses to store every version of your project. When you run `git init` inside a project folder, Git creates a hidden `.git` subdirectory that holds all history, configuration, and metadata. Nothing outside that folder is affected. You can verify it exists with `ls -a`.
Git tracks your work through three distinct areas:
- Working tree – the actual files you edit on disk.
- Staging area (index) – a holding zone where you assemble the exact set of changes that will go into your next commit.
- Repository (commit history) – the permanent, tamper-evident record of every snapshot you have committed.
Understanding this three-stage model is the single most important concept in Git. Changes do not go from disk to history automatically; you always decide what to stage and what to commit.
Initializing a Repository
Navigate to your project directory in the terminal and run:
```bash
git init
```
Git responds with a message confirming the empty repository was created. Before making any commits, confirm your name and email are set, because Git embeds them in every commit:
```bash
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
```
These settings are stored in `~/.gitconfig` and apply to all repos on the machine unless overridden locally.
Staging Files with git add
Creating or editing a file does not automatically record it. You must stage it first:
```bash
git add index.html
```
To stage multiple files at once you may list them individually or use `git add .` to stage everything in the current directory. Staging files individually gives you fine-grained control and is considered best practice, especially when different files represent different logical changes.
Run `git status` at any time to see which files are untracked, modified, staged, or clean. Reading `git status` output before every commit is a professional habit that prevents accidental commits.
Writing Well-Formed Commit Messages
A commit message is the human-readable record of why a change was made. The Conventional Commits format used widely in industry structures messages like this:
```
type: short subject line (50 characters or fewer)
Body paragraph explaining the motivation and context.
Wrap lines at 72 characters. Use present-tense imperative
verbs: "add", "fix", "update", not "added" or "fixes".
```
Common type prefixes: `feat` (new feature), `fix` (bug fix), `docs` (documentation), `style` (formatting), `refactor`, `test`, `chore`.
Example of a well-formed message:
```
feat: add navigation bar to index.html
Adds a top-level nav element with links to About and Contact
pages so users can move between sections without using the
browser back button.
```
Poor messages such as "stuff" or "fix" tell future collaborators (and your future self) nothing useful.
Inspecting Status and History
`git status` shows the state of your working tree and staging area at a glance.
`git diff` shows line-by-line changes in the working tree that have not yet been staged. `git diff --staged` shows what is staged but not yet committed.
`git log` lists every commit in reverse chronological order with the full hash, author, date, and message. For a compact view:
```bash
git log --oneline --graph
```
This prints a single line per commit with a visual branch graph — very useful when you need to compare several commits quickly.
Undoing Changes Safely
Git provides several safe ways to undo work without losing history:
| Situation | Command |
|---|---|
| Discard unstaged edits to a file | `git restore <file>` |
| Unstage a file (keep edits on disk) | `git restore --staged <file>` |
| Undo a commit by adding a new commit | `git revert <commit-hash>` |
`git revert` is the safe, professional choice for undoing commits that have already been shared with others. It creates a new commit that reverses the changes of the target commit, preserving the full history. Never use history-rewriting commands on commits that others may already have.
Workplace Safety Note
Version control work is performed entirely on a workstation. Follow your lab's posted ergonomics guidelines: adjust chair and monitor height, take regular breaks to avoid repetitive strain, and keep cables managed so walkways remain clear. Never leave a terminal session unattended and unlocked on a shared machine — log out or lock the screen when stepping away to protect project integrity and comply with your program's acceptable-use policy.
Lab Log Requirement
For every command you run in this lab, record the command, a brief description of what it does, and the key portion of the terminal output in your lab log. This written record reinforces learning and is required for instructor sign-off.
Key terms9
Materials: Git-configured workstation, terminal, text editor (VS Code or nano), lab log, Pro Git book chapter 2
Check: Repository contains at least six meaningful commits with correctly formatted messages; git log output reviewed by instructor; lab log entry earns instructor sign-off; 80% pass threshold on embedded checkpoint quiz.
Practice check8
Answer each question, then check it. Nothing is recorded; this is your own practice.
