6.0 What is Configuration Management?

Configuration management (CM) is the practice of tracking and controlling changes to software artifacts over time. Every file in a project - source code, tests, documentation, build scripts - is a managed artifact. CM answers: what changed, when, by whom, and why? Git is the dominant CM tool. It records a complete history of every change, supports parallel lines of development through branches, and enables teams to collaborate without overwriting each other's work. GitHub is the most widely used platform for hosting git repositories and coordinating collaborative work.

6.1 Git Basics

Git stores history as a directed acyclic graph of commits. Each commit records a snapshot of the repository state, a message, a timestamp, and a pointer to its parent commit(s).

Core Git Commands

Command	What it does
git init	Create a new git repository in the current directory.
git clone <url>	Copy a remote repository to the local machine.
git status	Show the state of the working tree and staging area.
git add <file>	Stage a file for the next commit.
git add -p	Interactively stage individual hunks of changes.
git commit -m "msg"	Record staged changes as a new commit with a message.
git log --oneline	Show a compact list of recent commits.
git diff	Show unstaged changes relative to the last commit.
git diff --staged	Show staged changes relative to the last commit.
git show <hash>	Show the diff and metadata of a specific commit.
git restore <file>	Discard unstaged changes to a file.
git reset HEAD <file>	Unstage a file without discarding changes.

The three areas of git:

• Working tree - files as they exist on disk; changes here are untracked until staged.
• Staging area (index) - changes marked for the next commit. Staging lets you compose commits precisely.
• Repository - the complete commit history stored in .git/.

6.2 Branches and Merging

A branch is a lightweight, movable pointer to a commit. Creating a branch costs almost nothing and lets you develop a feature or fix in isolation without affecting the main line of work.

# create and switch to a new branch
git checkout -b feature/regex-flags

# ... make commits on the feature branch ...

# switch back to main and merge
git checkout main
git merge feature/regex-flags

# delete the branch after merging
git branch -d feature/regex-flags

When two branches modify the same part of a file, git reports a merge conflict. You resolve it by editing the conflicted file, marking the conflict resolved with git add, and completing the merge with git commit. Rebase is an alternative to merge that rewrites branch history to produce a linear sequence of commits. git rebase main replays your branch's commits on top of the current tip of main. The result is a cleaner history but rewrites commits - never rebase commits that have been pushed to a shared remote.

6.3 Remote Repositories and GitHub

A remote is a version of the repository stored on another machine or a hosting service. GitHub, GitLab, and Bitbucket are the major hosting platforms.

Remote Workflow Commands

Command	What it does
git remote add origin <url>	Register a remote named "origin".
git push -u origin main	Push local main to origin and set tracking.
git push	Push current branch commits to the tracked remote branch.
git fetch	Download remote changes without merging.
git pull	Fetch and merge (or rebase) remote changes into current branch.
git pull --rebase	Fetch remote changes and rebase local commits on top.

GitHub pull requests (PRs) are the standard mechanism for code review before merging a feature branch into main. The workflow is:

1. Create a feature branch and push it to the remote.
2. Open a pull request on GitHub - describe the change and its purpose.
3. Team members review the diff, leave comments, and request changes.
4. After approval, merge the PR into main (squash, merge commit, or rebase).
5. Delete the feature branch.

6.4 Branching Workflows

Teams adopt conventions for which branches exist and how changes flow between them. Three common workflows:

• GitHub Flow - one long-lived branch (main) plus short-lived feature branches. Simple and suitable for continuous deployment.
• Git Flow - long-lived main and develop branches, plus feature, release, and hotfix branches. More structure, suited to versioned releases.
• Trunk-based development - very short-lived feature branches (or direct commits to main) behind feature flags. Maximizes integration frequency; requires strong automated testing.

6.5 References

Git References

Resource	Description
Pro Git (free online)	Complete git reference from first commits through advanced internals.
GitHub Flow	GitHub's guide to the GitHub Flow branching model.
Git Flow	The original Git Flow article by Vincent Driessen.
SW Deploy Bites: Git	Git configuration management from the Deploy Bites sequence in this track.