Git Basics Every CI Pipeline Relies On

CI is triggered by Git events, so understanding commits, branches, and remotes is the foundation for everything that follows.

Every CI pipeline reacts to something happening in Git - a commit, a push, a pull request. If you are fuzzy on Git's core concepts, the pipeline will feel like magic. This lesson covers just enough Git to make CI make sense.

Commits: snapshots of your code

A commit is a saved snapshot of your project at a point in time, identified by a unique hash like a1b2c3d. Each commit records what changed and points to its parent, forming a history. CI almost always runs against a specific commit - when you see a pipeline result, it is reporting on exactly one commit's state of the code.

Branches: parallel lines of work

A branch is a movable pointer to a commit, letting you develop a feature without disturbing the main line. The default branch (usually main) holds the canonical code. CI configuration often treats branches differently - for example, running the full suite on main but a lighter set on feature branches, or only deploying from main.

Remotes: the shared source of truth

A remote is a copy of the repository hosted somewhere shared, like GitHub. origin is the conventional name for your main remote. You push commits to the remote and pull others' work down. CI runs on the *remote*: pushing a branch to GitHub is what wakes the pipeline up, which is why work only stuck on your laptop never gets tested.

The commands you will see constantly

terminal

# Save your work as a commit
git add .
git commit -m "Add login validation"

# Send it to the shared remote (this triggers CI)
git push origin my-feature-branch

Key takeaways

A commit is an immutable snapshot CI runs against.
Branches let you work in parallel; CI can treat them differently.
CI runs on the remote, so pushing is what triggers it.