~/cloud-plus/modules/source-control.md

bash — repo

# Source Control Concepts

Application code, IaC deployment files, CaC configs — all of it changes constantly, and someone needs to know which version is the real one. Git is how that gets tracked.

GitVersion ControlGitHub Actions Exam Objective 5.1

8.23–24 Source control 8.25 Use cases 8.26–27 Repos & commands Git flow 8.28 Local repo 8.29 Branching 8.30 Pull requests 8.31 Code review 8.32 GitHub Actions

---

Lesson Introduction

Code management spans developer code, Infrastructure as Code deployment projects, and Configuration as Code tasks.

Code naturally evolves — so tracking and identifying the definitive current version is critical.

This lesson covers Git, one of the most common source control tools.

EXAM OBJ 5.1

Explain source control concepts. Expect the exam to test whether you can name a Git subcommand from its description, place a change correctly in the working directory → staging → local repo → remote repo flow, and recognize a use case, a code review type, or a GitHub Actions capability from a scenario.

Objectives

What you'll cover

Click one off as you go.

• Explain why version control matters for code, IaC, and CaC files.
• Walk a change through the Git flow — working directory to remote repository.
• Explain branching, pull requests, code review, and GitHub Actions.

0 / 3 reviewed

8.23 – 8.24

Source control & version management

Automation and configuration management run on files — the settings and provisioning details that Ansible, Docker, and other tools depend on. Managing those files carefully means borrowing a developer standard: Git. Files may live in a central repository, accessed, edited, and updated by many people at once, with a simple but robust set of commands tracking every change.

Version control matters most in collaborative environments — multiple developers touching the same code, some changes shipping new features, others fixing stability or security issues. Git tracks changes over time, maintains a central storage repository, checks code in and out, and merges changes to and from decentralized developer systems.

Git was released in 2005 by Linus Torvalds, the creator of Linux. Many proprietary version-control systems exist, but Git has become the de facto standard — especially for large, distributed projects where many programmers touch different parts of the same application. It supports nonlinear, collaborative development with strong file integrity.

8.25

Git concepts & use cases

Git isn't just for developers. Four common cloud/sysadmin use cases:

🖥 Standardized config files

15 identical Linux VMs need the same SSH daemon config. Keep the file in Git — change it once, copy the update to all 15.

🌐 Infrastructure as Code

Git stores standardized automation and orchestration files. Ansible servers pull configs from the repo — valid files reach every server, even on isolated segments.

📄 Script libraries

A centralized repository for the custom scripts sysadmins build up over time — shared, updated, and managed in one place instead of scattered locally.

👥 Development projects

Git's original purpose: collaborative, distributed teams tracking changes and maintaining a correct source of truth — whether in-house or worldwide.

8.26 – 8.27

Git repositories & commands

A Git repository is the storage area for a project's code versions and related files — on a single workstation, or centralized and cloned down to each developer's machine. Organizations can host their own on-premises repository or use a service like GitHub; a centralized repository isn't required.

Every Git task runs as a subcommand of git [options] {subcommand}. The ones marked ★ are the ones you'll actually reach for most.

Command	Description
config	Set options for a repository, Git users, or other global settings.
init	Create a Git repository, or reinitialize an existing one.
clone	Create a working copy of an existing repository.
add	Add files to be tracked by the Git repository.
commit	Update the repository with your changes — a "snapshot" of the project.
status	Display the status of the repository.
branch	Manage branches — pointers to specific snapshots after committing.
merge	Integrate changes from one branch into a "main" branch.
rebase	Rewrite Git history for a cleaner, more linear merge history.
pull	Acquire and merge changes from other repositories/branches into the local copy.
push	Upload a local working copy to a remote repository.
checkout	Switch to a specific branch to work with.
tag	Label a point in the repository's history — often a release.
show	Display information on the current branch's status.

Note for the exam: Git recently renamed a core concept — the "master" branch is now the "main" branch. merge integrates changes and keeps the real history; rebase does the same but rewrites history to look serial, even when work happened in parallel — for a cleaner, easier-to-review log.

The Git flow

Where a change actually lives

A change passes through four places before it's shared. Click a command to see what it does at that step.

8.28

Local Git repository, start to finish

Small teams often work from local repositories; cloud providers also host them, including AWS CodeCommit and Azure Repos. A typical first run looks like this:

1# set your identity once, globally

2$ git config --global user.name 'User'

3$ git config --global user.email 'user@domain.tld'

4

5# create the project directory and initialize it

6$ mkdir /dev-project

7$ git init /dev-project

8

9# track a file, tag a release point, commit a snapshot

10$ git add {filename}

11$ git tag -a v1.1 -m "Version 1.1"

12$ git commit -m 'Initial commit'

13

14# check what's tracked, added, or still pending

15$ git status

Working from an existing remote repository instead? git clone /dev-project pulls a working copy down first. And always work with copies of tracked files, not the originals — it makes rolling back a mistake trivial.

8.29

Branching & collaboration

A branch is a pointer to a snapshot — a safe place to make changes without touching main until they're ready.

main

newbranch

git merge newbranch →

1# create and work from a new branch

2$ git branch newbranch

3

4# fold the finished changes back into main

5$ git merge newbranch

6

7# pull a teammate's branch, push your own, review history

8$ git pull otherbranch

9$ git push <remote repository> mybranch

10$ git log --since=10.days

11$ git checkout specificbranch

git log shows what's merged and what else happened on the repo — useful for troubleshooting an issue introduced into configuration files, scripts, or anything else Git tracks. git checkout switches your working directory between branches of the same project.

8.30

Pull requests & repository files

A pull request asks project maintainers to review suggested changes and merge them if approved — the standard way contributors propose work on a shared or open-source project. Sample projects and hosting live on GitHub, GitLab, Bitbucket, and Digital Ocean, among others.

.gitignore

Lists files Git should skip during a commit — a README or a To-Do list that lives in the project directory but doesn't belong in version control.

.git/ directory

Where Git stores everything it uses to manage version control for the project. Created automatically by git init.

8.31

Code review

A quality-assurance practice: at least one developer who isn't the author reads and checks the code, to improve quality, catch errors before production, and suggest improvements. Sometimes called peer review — and mandatory in some industries.

Manual peer review is still standard, but AI-based review tools are now common — fast, consistent, and scalable, and able to reveal (and sometimes correct) errors, inefficiencies, and baseline deviations. The risk: leaning on AI too heavily, especially in code production, without a broader review strategy around it.

8.32

GitHub Actions

GitHub is more than an online repository — it's a hosting service with tools that simplify development. GitHub Actions automate development workflows inside the repository, triggered by external events, internal events, or a schedule.

Pull request approval

Automatically approve requests that meet defined criteria.

Automatic merges

Merge requests once conditions are satisfied.

Reviewer assignment

Automatically assign the right reviewers to a pull request.

Secret detection

Flag passwords or secrets accidentally inserted directly into code.

Vulnerability detection

Scan for known vulnerabilities in the code.

GitHub Actions supports common operating systems and programming languages, so compatibility is rarely a concern.

---

$ module --status

Source Control Concepts · Objective 5.1