Development Tooling and Version Control Basics
Development tooling and version control is the domain of how code is built, run, and shared. The exam tests the Git commands in a normal daily workflow, what the staging area is for, how branches and merges behave, and which tool - editor, linter, formatter, debugger, package manager - solves which problem.
The Git workflow
git init or git clone creates a repository. Edit files, then git add <file> stages changes, git commit -m 'message' records a snapshot, and git push publishes to a remote. git pull fetches and integrates. git status and git diff show what is staged and unstaged; git log --oneline shows history. A .gitignore keeps build artefacts, virtual environments, and secrets out of the repository.
Branches and merges
git switch -c feature creates a branch; work there and merge back with git switch main then git merge feature. A conflict occurs when both branches changed the same lines; Git marks the file with <<<<<<<, =======, and >>>>>>>, and you resolve it by editing, then git add and commit.
Worked example
You committed but forgot a file and have not pushed. Run git add missing.py, then git commit --amend --no-edit. The amend replaces the previous commit, so the history contains one clean commit. This rewrites history and is therefore unsafe once the commit is on a shared remote; in that case make a normal follow-up commit, or use git revert to undo it publicly.
Tooling
An IDE or editor provides navigation and a debugger. A linter flags suspicious code; a formatter enforces style; a test runner executes the suite. Package managers (pip, npm) install dependencies, and virtual environments isolate them per project.
Traps
- Committing API keys, credentials, or large binaries.
- Using
git reset --hardand losing uncommitted work. - Confusing
fetch(download only) withpull(download and merge). - Leaving conflict markers in a file.
- Committing directly to the main branch on a shared repository.