STEP8_GitCommits.md

Step 8: Git & Version Control

Professional software engineering requires Version Control. Git is the industry standard.

What NOT to Commit

Never commit generated files.

• BAD: demo.exe, scanner.o, build/
• WHY?: These can be regenerated from source. They bloat the repo and cause conflicts between OSes (Windows .exe vs Linux elf).

The .gitignore File

We created a .gitignore file to tell Git to ignore build/ and *.o. This ensures your repository stays clean.

Structured Commits

A good commit history tells a story.

Bad Commit Message:

"fixed stuff"

Good Commit Message:

"fix(scanner): handle null terminator correctly in peek()"

Conventional Commits (Industry Standard)

Format: <type>(<scope>): <description>

• feat: New feature
• fix: Bug fix
• docs: Documentation only
• style: Formatting, missing semi-colons, etc.
• refactor: Code change that neither fixes a bug nor adds a feature
• test: Adding missing tests

Example History for this project:

1. chore(init): initial project structure
2. feat(scanner): implement basic character reading
3. feat(tokenizer): implement token grouping logic
4. test(scanner): add unit tests for scanner
5. docs: add architectural overview

What you learned

• Clean Repo: Only source code goes in.
• Atomic Commits: Each commit should do one thing.
• Communication: Your commit log is a communication tool for your team (and future you).