Unit 11: Development Tools

I. Orientation: The Toolchain of Modern Engineering

Development tools are the software that lets engineers write, track, share and reason about code without losing history or overwriting one another's work. This unit centres on version control — the discipline of recording changes to a project over time — and on Git (created by Linus Torvalds, 2005) as its dominant implementation, extended by the GitHub hosting platform and by newer AI-assisted command-line tools.

• Repository (repo): the complete project plus its full change history, stored in a hidden .git folder at the project root.
• Commit: an immutable snapshot of the tracked files at one moment, identified by a 40-character SHA-1 hash (e.g. a1b2c3d…).
• Working directory, staging area, repository: the three zones a file moves through — edited, marked for inclusion, then permanently recorded.
• Distributed model: every clone holds the entire history, so work continues offline and no single server is authoritative by design.
• Convention: the default primary line of development is a branch named main (formerly master).

II. Version Control Concepts

Definition and Purpose

Version control is a system that records changes to files so that specific versions can be recalled, compared and merged later.

A. Why Version Control Exists

• History and rollback: every saved state is retrievable, so a broken change can be reverted to the last known-good commit.
• Collaboration: many engineers edit the same codebase concurrently, and the system reconciles their changes rather than letting the last save win.
• Traceability: each change carries an author, timestamp and message, answering who changed what, when and why.
• Experimentation: parallel lines of work (branches) let risky ideas be tried without endangering the stable version.

B. Centralised vs Distributed

Two architectures divide the field by where history lives.

1. Centralised (CVCS): a single server holds the one authoritative history (e.g. Subversion). Clients check out a working copy; losing the server or its network connection stalls all committing.
2. Distributed (DVCS): every clone is a full copy of the history (e.g. Git). Commits are local and instant; the network is needed only to share work, not to record it.

• Consequence: DVCS survives server loss because history is replicated across every developer's machine.

III. Git Fundamentals

Principle of Operation

Git tracks content as a series of snapshots, moving files through the working directory → staging area → repository, with each command below acting on one of those transitions.

A. git init

Initialises a new, empty Git repository in the current folder.

• Effect: creates the hidden .git directory holding all objects, refs and configuration.
• Scope: run once per project; the folder becomes tracked from that point on.

git init            # start tracking the current directory

B. git add

Moves changes from the working directory into the staging area, marking exactly what the next commit will contain.

• Selective staging: git add file.py stages one file; git add . stages everything changed under the current path.
• Snapshot timing: the content is captured as it was when added — editing after add requires re-adding.

git add index.html          # stage a single file
git add .                   # stage all current changes

C. git commit

Records the staged snapshot permanently in the repository as a new commit.

• Message requirement: -m supplies a short description; a good message states why the change was made, not just what.
• Identity: the commit stores author, timestamp and a pointer to its parent commit, forming a linked chain.

git commit -m "Add login form validation"

D. git status

Reports the current state of the working directory and staging area.

• Three categories shown: staged (ready to commit), modified but unstaged, and untracked (never added).
• Guidance: the output suggests the next command, e.g. what to add or how to discard changes.

git status          # see what is staged, modified or untracked

E. git log

Displays the commit history, newest first.

• Fields per entry: commit hash, author, date and message.
• Useful flags: --oneline condenses each commit to one line; --graph draws branch structure as ASCII art.

git log --oneline --graph   # compact, visual history

IV. Git & GitHub Fundamentals

Purpose and Principle

GitHub is a web platform that hosts Git repositories remotely, adding collaboration features (issues, reviews, access control) on top of Git's core commands. The following terms describe how local Git work synchronises with a shared remote.

A. Repository

The unit of storage holding a project and its full history, either local or remote.

• Local repo: the .git folder on your machine, created by init or clone.
• Remote repo: the copy hosted on GitHub, referenced by a short name, conventionally origin.
• Public vs private: visibility is set on GitHub, controlling who can read or contribute.

B. Clone

Copies an existing remote repository, with its entire history, onto the local machine.

• One-time setup: clone replaces init when a project already exists remotely.
• Automatic link: the source URL is saved as origin, so later pushes and pulls need no URL.

git clone https://github.com/user/project.git

C. Push

Uploads local commits to the remote so others can access them.

• Direction: local → remote; only commits (not unstaged edits) are transferred.
• Tracking: git push -u origin main sets main to track the remote branch, so later a bare git push suffices.

git push -u origin main

D. Pull

Downloads commits from the remote and integrates them into the current local branch.

• Two-step nature: pull = fetch (download) + merge (integrate).
• Purpose: keeps the local branch current before adding new work, reducing conflicts.

git pull origin main

E. Branching

Creates an independent line of development that diverges from the main history.

• Isolation: work on a feature or fix without affecting main.
• Cheapness: a branch is merely a movable pointer to a commit, so creating one is near-instant.

git branch feature-login    # create branch
git checkout feature-login  # switch to it
# or, combined:
git switch -c feature-login

F. Merge

Combines the changes from one branch into another, unifying two histories.

1. Fast-forward merge: when the target branch has no new commits, the pointer simply advances — no separate merge commit.
2. Three-way merge: when both branches advanced, Git creates a merge commit with two parents, reconciling the divergent changes.

• Merge conflict: occurs when the same lines changed on both branches; Git marks the region with <<<<<<<, =======, >>>>>>> and the developer resolves it manually.

git checkout main
git merge feature-login

G. Pull Requests

A GitHub feature proposing that one branch's changes be merged into another, wrapped in a review workflow.

• Not a Git command: a PR is a platform construct built around a branch comparison.
• Review cycle: teammates comment, request changes and approve before merging.
• Gatekeeping: automated checks (tests, linters) can be required to pass before the merge button unlocks, protecting main from broken code.

V. AI-Assisted CLI Tools

Definition and Principle

AI-assisted CLI tools embed large-language-model reasoning directly into the terminal, translating natural-language intent into shell commands and reasoning about code, so routine development tasks are driven by description rather than memorised syntax.

A. What They Do

• Command generation: describe a goal in plain English — "undo my last commit but keep the changes" — and the tool proposes git reset --soft HEAD~1.
• Error explanation: paste a failing stack trace or Git error and receive a diagnosis plus a fix.
• Code and commit assistance: draft commit messages from a diff, scaffold files, or explain unfamiliar code inline.
• Examples: GitHub Copilot CLI, Amazon Q / Kiro CLI, and other agentic terminal assistants.

B. Benefits and Limitations

The value of these tools is speed and lowered syntax barriers, offset by the need for human oversight.

1. Benefits: reduce time spent recalling flags, surface commands a beginner would not know, and explain output in context — accelerating both learning and routine work.
2. Limitations: suggestions can be confidently wrong, may propose destructive commands (e.g. git reset --hard), and can leak context if run against sensitive code.

• Best practice: treat suggestions as drafts — read every generated command before running it, and never execute an irreversible operation without understanding its effect.
• Verification anchor: confirm a proposed Git command with git status before and after, so the tool's action is checked against real repository state.