Glossary A–Z

Every term in one place, explained for someone with no technical background. Across the course, a word with a dotted underline is a glossary term: hover or tap it for the short definition, click it to come here.

Action (GitHub Actions)

A reusable step that someone else published, used inside a GitHub workflow instead of writing the commands yourself.

A workflow step either runs a command (run) or uses an action (uses), such as actions/checkout to fetch the repository. Actions are pinned to a version, which is why you see @v4 at the end of one.

Example: The trailguide workflow uses actions/setup-python@v5 to install Python before running the tests.

Related: pipeline, ci, artifact. Lesson: GitHub Actions.

API

The rules by which one program talks to another over a network: which requests it accepts and what it answers.

"API" stands for application programming interface. Developers say "the API changed" when the agreement between two programs changed, which is why version numbers exist. You may be asked to document one.

Example: The trail app's web version asks a server "give me the trails in region North" through its API.

Application

A program that people use: a website, a phone app, a command-line tool. It is built from source code.

Also called the app, the service, or the product. The application runs; the source code is what developers write and what Git stores.

Example: trailguide is the application; src/trailguide.py is its source code.

Related: source code, project, build. Lesson: What software development is.

Artifact

A file produced by a build or a pipeline job, kept so that the same tested result can be downloaded or deployed.

Artifacts are stored by GitLab or GitHub next to the pipeline run: a compiled program, a package, a report, a rendered documentation site.

Example: The docs pipeline produces the rendered site as an artifact; the Pages job deploys exactly that artifact.

Related: build, pipeline, deployment. Lesson: Dependencies, build, runtime.

Backlog

The ordered list of issues the team might work on, not yet scheduled into a sprint.

Product people keep it prioritized; the top of the backlog is what gets picked next.

Example: Ana's "add a glossary page" issue waits in the backlog until the next sprint planning.

Related: issue, sprint, board. Lesson: Agile in one page.

Board

Issues shown as cards in columns that represent states: to do, doing, in review, done.

Cards move as work progresses; on GitLab and GitHub the moves often follow Git events such as opening or merging a merge request.

Example: Opening the merge request for #12 moves its card from "Doing" to "In review".

Related: issue, merge request, definition of done. Lesson: Agile in one page.

Branch

A movable label that points at a commit, so you can work on changes separately from the main line until they are ready.

Creating a branch costs nothing and changes no files. Each branch remembers its own newest commit; when you commit on a branch, the label moves forward. Teams give branches names such as docs/12-windows-install-steps so everyone can see what the work is for.

Example: Ana creates the branch docs/12-windows-install-steps, edits the installation guide there, and the main branch stays untouched until her merge request is approved.

Related: main, commit, merge, head. Lesson: What a branch really is.

Bug

Behaviour that does not match what was intended; an issue of the kind "fix".

Bugs are tracked as issues with a bug label and fixed on fix/ branches; urgent ones become hotfixes.

Example: Issue #15, "Trail list crashes when a distance is empty".

Build

The automated process that turns source code into something that runs or can be shipped, and also its result.

Compiled languages need a build; interpreted ones such as Python often do not. Build output (build/, dist/) is regenerated from source and never committed.

Example: "The build takes six minutes and produces dist/trailguide-web.zip."

Related: artifact, pipeline, runtime. Lesson: Dependencies, build, runtime.

Continuous delivery / deployment (CD)

Automatically preparing every merged change for release (delivery) or automatically putting it into production (deployment).

Continuous delivery stops at "ready to deploy with one click"; continuous deployment goes all the way. Both build on continuous integration.

Example: Every merge to main deploys the docs site automatically: continuous deployment for documentation.

Changelist

IntelliJ IDEA's own grouping of pending changes, used to keep unrelated edits apart before committing.

It is not a Git feature: git status and your colleagues cannot see it. Turning on the staging area in settings gives you Git's index instead, which the terminal and the IDE then describe identically.

Example: Ben keeps his fix in one changelist and his debugging print statements in another, and commits only the first.

Changelog

A file listing what changed in each released version, written for the people who use the software rather than for the people who wrote it.

Usually CHANGELOG.md, with sections such as Added, Changed, Fixed and Removed. Entries are cheapest to write as each change is merged, under an "Unreleased" heading that becomes the version number on release day.

Example: "Fixed: the list no longer crashes when a trail has no distance (#15)."

Cherry-pick

Copying the change from one commit onto the branch you are on, as a new commit with a new hash.

It copies rather than moves, so the original stays where it was. It is how a fix on main reaches a release branch, and how a commit made on the wrong branch is rescued.

Example: Ben cherry-picked the empty-distance fix from main onto release/1.2 so customers on 1.2 got it too.

Related: commit, hash, revert. Lesson: Cherry-pick.

Continuous integration (CI)

Automatically building and testing every change as soon as it is pushed, so problems surface within minutes.

The pipeline runs the same commands developers run locally; a red pipeline blocks the merge.

Example: Ana's push triggers the Markdown check; a skipped heading level turns it red, and she fixes it before review.

Clone

Copy a whole remote repository, including its full history, onto your computer.

git clone creates the folder, downloads every commit, sets up the remote name origin, and checks out the default branch so you can start working. You clone once per project per computer; after that you use pull and push to stay in sync.

Example: git clone https://gitlab.com/northwind-trails/trailguide.git creates a trailguide folder with the project and its history.

Related: remote, origin, pull. Lesson: clone, remote, fetch, pull, push.

Code review

Colleagues reading a proposed change on a merge request or pull request, commenting, suggesting edits, and approving.

Review applies to documentation as much as code. The author answers comments and pushes more commits until the reviewers approve.

Example: Dev suggests a clearer sentence on Ana's merge request; she applies the suggestion with one click and he approves.

CODEOWNERS

A file mapping paths in a repository to the people or teams who must review changes to them.

The platform reads it and requests those reviews automatically. The last matching rule wins, which is the opposite of what most people expect. Being listed for the documentation paths turns "remember to ask Ana" into an automatic review request.

Example: /docs/ @northwind-trails/docs means every change under docs/ needs a docs-team review.

Related: code review, protected branch, reviewer. Lesson: Team conventions.

Codespace

A development machine that runs in the cloud, opened from a GitHub repository, with an editor and a terminal.

Unlike the browser editor at github.dev, a codespace can install dependencies, run the project and execute tests, because there is a real machine behind it. It costs quota beyond a monthly allowance.

Example: Ana opens a codespace to run the trail program herself before approving a change to its error messages.

Commit

A saved snapshot of the project at one moment, with a message saying what changed, who made it, and when.

A commit records the exact content of every tracked file, not only the files you touched. Each commit gets a unique hash and remembers its parent commit, which is how history becomes a chain. Commits are permanent in practice: even "undoing" a commit creates a new one.

Example: After fixing a typo in docs/faq.md, Ana runs git commit -m "docs: fix typo in FAQ" and Git stores the snapshot as commit 3c4d5e6.

Related: staging area, hash, log. Lesson: Committing and good messages.

Configuration

Settings a program reads when it starts, kept outside the source code so that the same build behaves differently per environment.

Configuration lives in files (config.yml) or environment variables. Templates are committed; real values, especially secrets, are not.

Example: The same trail app talks to a test database on staging and the real one in production, chosen by configuration.

Definition of done

The team's written checklist of what must be true before an issue counts as finished.

It turns "done" from an opinion into a standard: reviewed, tests green, documentation updated, merged, deployed. Merge request templates make it concrete.

Example: For Northwind Trails, a feature is done only when its FAQ entry is merged too.

Related: board, merge request, issue. Lesson: Agile in one page.

Dependency

A library or package that a project needs in order to run or be built, written by someone else.

The list of dependencies (the manifest and lock file) is committed; the installed copies (node_modules/, .venv/) are ignored.

Example: A web project depends on 800 packages; the playground depends on nothing but Python.

Deploy key

An SSH key added to one repository rather than to a person, so a server can clone it without anyone's account.

Read-only unless write access is ticked. It is the right credential for a build or documentation server, because it reaches one repository and does not leave when a person does.

Example: The documentation server clones trailguide with a read-only deploy key.

Deployment

Putting a specific build of the application into an environment so that it runs there.

"Merged" and "deployed" are different events: users see a change only after it is deployed to production. Pipelines deploy automatically to early environments and on request to production.

Example: Ana's FAQ change is merged on Monday but reaches production with Thursday's deployment.

Detached HEAD

The state where HEAD points directly at a commit instead of at a branch, typically after checking out an old commit or a tag.

Nothing is broken; but commits made in this state belong to no branch and are easy to lose. Leave with git switch -, or keep new work with git switch -c new-branch.

Example: git checkout v1.2.0 to read the FAQ as it was at the release; git switch - to return.

Related: head, branch, tag. Lesson: HEAD, refs, origin, upstream.

Diff

The list of exact line-by-line changes between two versions of your files.

Lines that were removed are marked with - and lines that were added with +. git diff shows what you changed but have not staged; git diff --staged shows what will go into the next commit; GitLab and GitHub show the same thing visually in a merge request.

Example: Before committing, Ben runs git diff and sees the one line he changed in src/trailguide.py, plus a debug line he forgot to remove.

Related: staging area, commit. Lesson: git diff in three forms.

Distributed version control

A design where every copy of the repository contains the full history, so work, commits and history browsing happen offline.

Git is distributed; the team simply agrees on one copy (GitLab or GitHub) as the meeting point. This is why commit and push are separate steps.

Example: GitLab is down for an hour; everyone keeps committing and pushes later.

Related: git, remote, push. Lesson: Why version control exists.

Editor

A program for writing plain text such as source code, Markdown and configuration, without hidden formatting.

VS Code is an editor that becomes an IDE through extensions; Git also opens your editor for commit messages when you omit -m.

Example: Ana writes every guide in VS Code with the Markdown preview open.

Related: ide, terminal, markdown. Lesson: IDE, terminal, shell, editor.

Environment

A complete place where the application runs — machines, runtime, configuration and data — such as local, development, test, staging or production.

Earlier environments are cheap to break; production is the real thing. A change travels through them by deployments.

Example: "It is on staging" means testers can see it; users cannot yet.

Environment variable

A named value the operating system hands to a program when it starts, used for settings that differ per environment or must stay secret.

Locally they often come from a .env file, which must be ignored by Git; on servers and in pipelines they are set as CI/CD variables or secrets.

Example: DATABASE_URL points at a different database on each environment.

Fast-forward

A merge where the target branch simply moves its label forward to the other branch's commit, because it had no new commits of its own.

No merge commit is created and no conflict is possible. git pull fast-forwards when you have no local commits.

Example: After the web edit, Ana's git pull reports "Fast-forward" and her main catches up.

Related: merge, pull, branch. Lesson: Merging.

Feature

Something new that users will notice; an issue of the kind "add", worked on a feature/ branch.

Features are usually larger than fixes and travel through review and testing before a release.

Example: Issue #21, "Add a difficulty filter to the trail list".

Feature flag

A setting that turns a piece of behaviour on or off without deploying anything, so unfinished work can be merged and shipped while staying invisible.

It separates deploying from releasing: the code goes out continuously, and the feature is switched on for the team, then for everyone. The fastest possible rollback is turning the flag off.

Example: The difficulty filter was in production for a week before anyone could see it, behind a flag.

Related: deployment, rollback, cd. Lesson: Environments, deployments, rollback.

Fetch

Download new commits from the remote into your local repository without changing any of your files.

Fetch is the safe way to see what the team has pushed: it updates the remote-tracking branches such as origin/main, and nothing in your working tree moves. You then decide whether to merge or rebase.

Example: Chloe runs git fetch before lunch, then git status tells her that main is behind origin/main by 2 commits.

Related: pull, remote, origin. Lesson: fetch vs pull.

Fork

Your own server-side copy of someone else's repository, used to propose changes to a project you cannot push to.

You push branches to your fork and open a merge request or pull request from it to the original.

Example: An outside contributor forks the public trailguide mirror to fix a link.

Related: clone, pull request, upstream. Lesson: Forks and the fork workflow.

Gist

A small set of files with its own URL on GitHub, used to share a fragment that belongs to no repository.

Gists are version controlled and can be cloned. A "secret" gist is unlisted rather than private: anyone with the link can read it, so never put a credential in one.

Example: Ben sends Chloe a gist containing the two commands that reproduce the crash.

Git

The program that records snapshots of a folder over time, so you can go back, compare versions, and work in parallel with other people.

Git runs on your computer and stores everything in a hidden .git folder inside the project. GitLab and GitHub are websites that host Git repositories and add teamwork features around them; Git itself works without them.

Example: Ana installs Git on her laptop, then uses VS Code (which runs Git behind the scenes) to save snapshots of the documentation she writes.

GitHub

A website that hosts Git repositories and adds pull requests, issues, code review, GitHub Actions (automation) and more.

GitHub belongs to Microsoft and hosts most open-source projects. The concepts are the same as GitLab's, with different names: a "pull request" on GitHub is a "merge request" on GitLab, and an "organization" is roughly a "group".

Example: The Northwind Trails team keeps a public mirror of trailguide on GitHub so outside contributors can open pull requests.

Related: gitlab, pull request, remote. Section: GitHub.

GitLab

A website, or a server a company runs itself, that hosts Git repositories and adds merge requests, issues, CI/CD pipelines, and more.

GitLab is the primary platform in this course. It organizes work into groups and projects, and its merge requests are where review and automated checks happen before a change reaches main.

Example: Ana opens a merge request on gitlab.com; the pipeline checks her Markdown, Dev approves, and the change is merged.

Related: github, merge request, remote. Section: GitLab.

.gitignore

A file listing patterns of files that Git should never track, such as build output, editor settings and files containing secrets.

Anything matching a pattern in .gitignore becomes ignored: git status stops mentioning it and git add . skips it. The file is itself committed, so the whole team ignores the same things.

Example: The trailguide project ignores __pycache__/, .venv/ and .env, so Ben's local Python files and his private API key never end up in a commit.

Related: ignored, untracked. Lesson: .gitignore.

Hash (SHA)

The unique id of a commit: a 40-character code, usually shown as its first 7 characters, such as 7a8b9c0.

Git computes the hash from the commit's content, so two different commits never share one. You use hashes to refer to a specific commit in commands such as git show 7a8b9c0 or git revert 7a8b9c0. Your own hashes will always differ from the ones in this course.

Example: Chloe reports "the bug appeared in commit 3c4d5e6", and Ben can look at exactly that snapshot.

Related: commit, log. Lesson: Commits, hashes and history.

HEAD

Git's name for "where you are right now": normally the newest commit of the branch you are on.

When you commit, HEAD moves forward with your branch. HEAD~1 means "one commit before HEAD". If HEAD points at a commit instead of a branch, you are in "detached HEAD" state, which the course explains in the recovery section.

Example: git show HEAD shows the last commit you made; git diff HEAD shows everything you changed since it.

Related: commit, branch, detached head. Lesson: HEAD, refs, origin, upstream.

Hotfix

An urgent bug fix that goes to production immediately, outside the normal release schedule, on a hotfix/ branch.

Hotfixes still get an issue and a fast review; what makes them special is the direct path to production.

Example: Issue #23, "Wrong region name shown for Harbour Path", fixed and deployed the same afternoon.

IDE

Integrated development environment: a code editor bundled with tools for running, testing and version control, such as VS Code or IntelliJ IDEA.

An IDE runs Git for you when you click buttons, which is why this course always shows the command underneath. Knowing the command means you are never stuck when a button moves.

Example: In VS Code, clicking the "+" next to a file runs git add on that file.

Related: terminal, git, editor. Sections: Git in VS Code, Git in IntelliJ IDEA.

Ignored

A file that matches a pattern in .gitignore; Git behaves as if it does not exist.

Ignored files stay on your disk and you can use them normally. They simply never appear in git status and never get committed. To see them anyway, run git status --ignored.

Example: Ben's .venv/ folder is 200 MB of Python packages; it is ignored, so it never slows down the repository.

Related: gitignore, untracked. Lesson: .gitignore.

Issue (ticket)

A numbered record of one piece of work: title, description, assignee, labels and discussion; the handle that links branches, commits and merge requests to the work.

GitLab and GitHub call them issues; Jira calls them tickets. #12 in a commit message or merge request becomes a link.

Example: Issue #12, "Installation guide is missing the Windows steps", closed by merge request !47.

Label

A coloured tag on an issue or merge request that marks its kind, area or priority, used for filtering and boards.

Example: documentation, bug, good first issue.

Related: issue, board, milestone. Lesson: Agile in one page.

Git LFS (Large File Storage)

An extension that keeps large files on a separate server and stores a small pointer file in the repository instead.

Git keeps every version of every file forever, which is fine for text and painful for video. The symptom that LFS is in use and not installed is opening an image and finding three lines of text mentioning oid sha256.

Example: The project stores its screencasts with LFS; a plain clone gets pointers until git lfs pull fetches the real files.

Related: repository, clone, gitignore. Lesson: Monorepos, LFS, submodules.

Local History

IntelliJ IDEA's record of every file save, refactoring and IDE action, kept independently of Git.

It is the only tool in this course that can recover work Git never saw: an edit discarded before committing, a file deleted before it was added, or changes lost to a hard reset. It is local, expires after a few days, and is a safety net rather than a backup.

Example: Chloe recovered a paragraph she had discarded by opening Local History on the file and copying it out of an older version.

Related: reflog, working tree, restore. Lesson: Shelve, stash, Local History.

Lock file

A generated file that records the exact versions of every dependency that was installed, so everyone installs precisely the same ones.

Never edited by hand; a package manager regenerates it. It is committed alongside the manifest.

Example: package-lock.json changes by 300 lines when Ben adds one library.

Log

The list of commits in the history, newest first, with their hashes, authors, dates and messages.

git log is how you answer "what happened, when, and who did it". git log --oneline shows one line per commit; IDEs and the web UIs show the same list with a graph.

Example: Before a release, Dev reads git log --oneline v1.2..main to see every change since the last version.

Related: commit, hash. Lesson: Reading history.

Logs (program output)

Lines a program writes about what it is doing and what went wrong, on screen, in files, or in a pipeline job's output.

Not stored in Git. The last line of an error is usually the one that matters; copy the whole message into bug reports.

Example: FileNotFoundError: [Errno 2] No such file or directory: 'data/trails.csv'.

main

The default branch: the version of the project the team treats as the current, working one.

Older projects call it master. Teams usually protect main so nobody can push to it directly; changes arrive through merge requests or pull requests after review.

Example: When Ana's merge request is approved and merged, her documentation change becomes part of main, and the next deployment includes it.

Related: branch, merge, protected branch. Lesson: Branch types and naming.

Maintainer

The person responsible for a repository's main branch: decides what gets merged, protects branches, cuts releases, and manages settings.

On GitLab it is also a role name; on GitHub the equivalent permission is "Maintain".

Example: Dev approves and merges Ana's merge requests and creates the v1.2.0 tag.

Related: reviewer, protected branch, release. Lesson: Roles on a team.

Markdown

A plain-text way to write documents (# heading, **bold**, - list) that GitLab, GitHub and many tools render as formatted pages.

Markdown files end in .md. Because they are plain text, Git can show exactly which lines changed, and reviewers can comment on a single line. README files, wikis, issues and merge request descriptions all use Markdown.

Example: Ana writes docs/getting-started.md in Markdown; on GitLab it appears with headings, links and a code block.

Related: repository, diff. Lesson: Markdown for documentation.

Merge

Combine the commits of one branch into another.

If the target branch has not moved, Git simply moves its label forward (a "fast-forward"). If both branches have new commits, Git creates a merge commit with two parents. When both sides changed the same lines, Git stops and asks you to resolve a conflict.

Example: Dev merges docs/12-windows-install-steps into main; the Windows steps are now in the official guide.

Related: branch, merge request, merge conflict, fast forward. Lesson: Merging.

Merge conflict

The situation where two branches changed the same lines of the same file differently, so Git cannot combine them and asks you to choose.

Git marks the conflicting region in the file; you edit it to the intended result, stage it, and finish the merge. Documentation files conflict as easily as code.

Example: Ana and Ben both edited the FAQ's first answer; Ana resolves the conflict by keeping both sentences.

Related: merge, branch. Lesson: Why conflicts happen.

Merge request (MR)

On GitLab: a request to merge your branch into another branch, with a description, reviewers, discussion, approvals and pipeline results all in one page.

A merge request is where teamwork happens: reviewers comment on specific lines, suggest changes, and approve. Only when the checks pass and the approvals are in does someone press Merge. GitHub calls the same thing a pull request.

Example: Ana opens MR !47 "Add Windows steps to installation guide (#12)"; Dev reviews it and merges it the same afternoon.

Related: pull request, merge, branch, code review. Lesson: Merge requests end to end.

Milestone

A goal with a date, usually a release, that groups the issues and merge requests meant to be part of it.

Example: Milestone v1.2.0 contains twelve issues; the release notes are its closed issues in prose.

Related: issue, release, sprint. Lesson: Agile in one page.

Modified

A tracked file whose content on disk differs from the last commit and has not been staged yet.

git status lists modified files under "Changes not staged for commit". Nothing is saved until you stage the change with git add and then commit.

Example: Ana edits README.md; git status shows modified: README.md in red until she runs git add README.md.

Related: staged, untracked, tracked. Lesson: File states.

Monorepo

One repository holding many projects: several applications, their shared libraries, the infrastructure and the documentation, versioned together.

A change spanning two projects is one merge request rather than two, at the cost of a larger clone and pipelines that must work out what changed. Ownership and CI rules are scoped by directory rather than by repository.

Example: In the monorepo, the docs team owns /docs rather than owning a separate documentation repository.

Related: repository, codeowners, pipeline. Lesson: Monorepos, LFS, submodules.

Organization

A GitHub account that belongs to a company or community rather than a person, holding repositories, teams and members.

Repositories in an organization outlive the people who created them, which is why shared work belongs there rather than in someone's personal account. Organizations do not nest; teams inside them do.

Example: northwind-trails is the organization that owns the trailguide repository.

Related: team, repository, project. Lesson: Organizations, teams, repositories.

origin

The default name Git gives to the remote you cloned from.

"origin" is only a nickname for a URL; you could rename it, but almost nobody does. origin/main is your local copy of what the remote's main looked like the last time you fetched.

Example: git push origin main means "send my main commits to the remote called origin".

Related: remote, clone, fetch, remote tracking branch. Lesson: What a remote is.

Package manager

The tool that installs a project's dependencies from its manifest and writes the lock file: pip for Python, npm for JavaScript, Maven for Java.

Example: npm install reads package.json, downloads 800 packages into node_modules/, and updates package-lock.json.

Related: dependency, lock file. Lesson: Dependencies, build, runtime.

Pipeline

The automated sequence of steps that runs after every push: build, test, lint, package, deploy.

Defined in .gitlab-ci.yml (GitLab) or a workflow file under .github/workflows/ (GitHub). Green means every job passed; red means stop and read the job log.

Example: The trailguide pipeline runs the tests and a Markdown check on every push.

Related: ci, cd, artifact, logs. Lesson: Pipeline, job, runner, artifact, environment.

Programming language

A language for writing instructions a computer can follow, such as Python, JavaScript or Java, written as plain text files.

Each language has its own tools: an interpreter or compiler, a package manager, test frameworks.

Example: trailguide.py is written in Python and run with python3.

Related: source code, runtime, build. Lesson: What software development is.

Project

The folder with everything needed to build and run an application: source code, tests, documentation, data, configuration.

On GitLab, "project" also means the page that contains a repository plus its issues, merge requests, pipelines and settings.

Example: The trailguide/ folder is the project; on gitlab.com it is the project northwind-trails/trailguide.

Protected branch

A branch, usually main, that the platform guards: no direct pushes, no force pushes, no deletion; changes arrive only through reviewed merge requests.

Example: Ana's push to main is refused; she opens a merge request instead, as intended.

Related: main, merge request, maintainer. Lesson: Protected branches.

Pull

Fetch the new commits from the remote and merge (or rebase) them into your current branch, in one command.

git pull = git fetch + git merge. It changes your files, so run it when your work is committed or stashed. If the remote and you changed the same lines, the merge can produce a conflict.

Example: Every morning Chloe runs git pull on main before starting a new branch, so her branch starts from the latest version.

Related: fetch, merge, push, fast forward. Lesson: fetch vs pull.

Pull request (PR)

On GitHub: a request to merge your branch into another branch, with review, discussion, checks and approvals. The same idea as a GitLab merge request.

The name comes from asking the maintainer to "pull" your changes. Everything you learn about merge requests applies to pull requests; only the buttons and some words differ.

Example: An outside contributor opens PR #88 on the GitHub mirror of trailguide to fix a broken link.

Related: merge request, merge, code review. Lesson: Pull requests end to end.

Push

Upload the commits from your local branch to the remote so other people (and the pipeline) can see them.

Push only sends commits, never uncommitted edits. If someone else pushed to the same branch first, Git rejects your push until you fetch and integrate their commits.

Example: Ana runs git push -u origin docs/12-windows-install-steps and GitLab replies with a link to create a merge request.

Related: pull, remote, commit. Lesson: clone, remote, fetch, pull, push.

Rebase

Taking the commits a branch added and applying them again on top of a different starting commit, so the history becomes a straight line.

The replayed commits are new commits with new hashes, which is why a rebased branch that was already pushed needs git push --force-with-lease. Safe on a branch only you have; disruptive on a branch someone else works on.

Example: Ana rebases her documentation branch onto today's main before review, so the merge request shows only her change.

Related: merge, rewriting history, hash. Lesson: Rebasing explained.

Ref

A named pointer to a commit: a branch, a tag, or a remote-tracking branch, stored as a tiny file under .git/refs.

Refs are what let people say main or v1.2.0 instead of a hash.

Example: .git/refs/heads/main contains the hash of the newest commit on main.

Related: branch, tag, head. Lesson: HEAD, refs, origin, upstream.

Reflog

Git's private diary of every position HEAD and each branch has held in your clone, which is what makes a "lost" commit findable again.

It is local: never pushed, never fetched, and it keeps entries for about ninety days. git reflog lists it, and resetting to one of its entries brings back a commit that git log can no longer see.

Example: After a hard reset removed her afternoon's work, Ana found it in git reflog and restored it with one command.

Release

A named version of the software handed to users, with release notes; in Git, a tag on a commit plus notes and artifacts on the platform.

Released is not the same as deployed: a release exists as a version; a deployment puts it into an environment.

Example: "trailguide 1.2.0 released, adds the --longest option".

Related: version, tag, deployment. Lesson: Tags, releases, semantic versioning.

Remote

A copy of the repository stored somewhere else, usually on GitLab or GitHub, that the whole team shares.

Your local repository and the remote each hold the full history. You bring their commits to you with fetch or pull and send yours with push. Most projects have one remote, named origin.

Example: The team's remote is https://gitlab.com/northwind-trails/trailguide; each team member has their own local clone.

Related: origin, clone, push, fetch. Lesson: What a remote is.

Remote-tracking branch

Your local bookmark of where a remote branch was the last time you fetched or pushed, named like origin/main.

It moves only on fetch, pull and push, never when you commit; "up to date with origin/main" means up to date with this bookmark, not necessarily with the server right now.

Example: After git fetch, origin/main jumps ahead and git status says your branch is behind.

Related: origin, fetch, tracking branch. Lesson: HEAD, refs, origin, upstream.

Repository (repo)

A project folder whose history Git tracks; the history lives in a hidden .git folder inside it.

Everything Git knows about the project — every commit, branch and tag — is inside .git. Delete that folder and you have an ordinary folder again. On GitLab a repository lives inside a "project"; on GitHub the repository is the project.

Example: trailguide/ is a repository: it contains the code, the docs, and a .git folder with 214 commits of history.

Related: git, working tree, remote. Lesson: init vs clone; the .git folder.

Requirement

Something somebody needs from the software, before it is written down as an issue.

Example: A customer emails "the guide should explain Windows installation"; it becomes issue #12.

Restore

The command that brings a file back to a known state: it discards your edits or removes a file from the staging area.

git restore <file> throws away uncommitted edits to that file (this cannot be undone). git restore --staged <file> only unstages, keeping your edits. Older guides use git checkout -- <file> for the same thing.

Example: Ana accidentally deletes a paragraph in docs/faq.md; git restore docs/faq.md brings the committed version back.

Related: staged, modified, working tree. Lesson: Undo, beginner edition.

Revert

Undo a commit by creating a new commit that applies the opposite change, leaving history intact.

Safe on shared branches because it adds rather than rewrites; the usual way to undo something that was already pushed.

Example: Chloe's pushed change breaks the pipeline; git revert HEAD and a push make it green again in two minutes.

Related: commit, rewriting history. Lesson: Undo, beginner edition.

Reviewer

A colleague who reads a merge request or pull request, comments, suggests changes, and approves or requests changes.

Any team member can review; documentation changes benefit from a reviewer who checks accuracy and one who checks wording.

Example: Ben reviews the technical content of Ana's guide; Dev gives the final approval.

Related: code review, maintainer, merge request. Lesson: Roles on a team.

Rewriting history

Replacing existing commits with new ones (different message, content, order or parent), which gives them new hashes.

Fine on your own unpushed work (amend, squash); disruptive on branches other people have, because their copies no longer match. The one rule: rewrite only what you have not pushed.

Example: Ana amends a pushed commit and git status reports her branch and origin/main "have diverged".

Related: commit, hash, revert. Lesson: What rewrites history and what does not.

Rollback

Deploying the previous version again because the new one misbehaves; sometimes done in Git with a revert.

Example: Release 1.2.1 crashes on startup; operations roll back to 1.2.0 while the fix is prepared.

Ruleset

A named list of rules on GitHub controlling what may happen to a branch or tag: required reviews, required checks, no force pushes.

Several rulesets can apply to one branch, and they are enforced alongside the older branch protection rules, with the most restrictive version of a rule winning. Anyone with read access can see the active ones.

Example: The ruleset on main requires a pull request, one approval and a green check before merging.

Runner

The machine that executes a CI/CD job, usually a fresh container created from an image and thrown away afterwards.

Because it starts clean and clones only what was pushed, a job can fail while the same commands pass on your computer: a different version, a missing dependency, or a file you never committed.

Example: The tests job runs on a runner using the python:3.13-slim image, which is why it does not have the packages installed on Ana's laptop.

Runtime

The software that executes a program: the Python interpreter, the Java Virtual Machine, Node.js, a browser.

Runtimes have versions; projects pin the version they need, often in the pipeline definition, which is why "it works on my machine" usually means a version difference.

Example: The pipeline runs the tests with python:3.12 whatever is installed on each laptop.

Related: build, dependency, pipeline. Lesson: Dependencies, build, runtime.

Semantic versioning

The convention of numbering releases MAJOR.MINOR.PATCH, where each part is a specific promise to whoever depends on the project.

Major means something that used to work no longer does; minor means new behaviour with nothing broken; patch means a fix and nothing else. Renaming an option or changing a default is a breaking change, even though it feels small.

Example: 1.2.1 fixed a bug, 1.3.0 added the difficulty filter, and 2.0.0 renamed an option people had scripted.

Shell

The program inside the terminal that reads what you type and runs it: zsh, bash, PowerShell, or Git Bash on Windows.

The terminal is the window; the shell is the interpreter behind it. This course uses bash-style commands, which work in Git Bash, macOS and Linux.

Example: echo $SHELL prints /bin/zsh on a Mac.

Related: terminal, editor. Lesson: IDE, terminal, shell, editor.

Shelving

IntelliJ IDEA's way of setting pending changes aside, similar to a stash but the IDE's own and invisible to Git.

Unlike git stash, shelving is selective: you can shelve two files out of five. Smart Checkout uses it behind the scenes when you switch branches with uncommitted work, which is where "my changes disappeared" usually comes from.

Example: Ana shelved the FAQ edits, switched branches to answer a question, and unshelved them when she came back.

Snippet

A small set of files with its own URL on GitLab, used to share a fragment that belongs to no project.

Snippets are version controlled, hold up to ten files, and can belong to a project or to you personally. A project snippet is never more visible than its project.

Example: The team keeps the sample configuration file as a project snippet rather than re-sending it.

Related: gist, project, markdown. Lesson: Wiki, snippets, Pages, Web IDE.

Source code

The human-written text instructions that make up a program, kept in plain text files that Git tracks.

Source code is the original; builds and running applications are produced from it.

Example: The 60 lines of src/trailguide.py.

Sprint (iteration)

A fixed period, often two weeks, in which the team commits to a chosen set of issues.

Tracked with milestones or iterations; ends with a review and a retrospective.

Example: Sprint 14 contains the twelve issues of milestone v1.2.0.

Related: backlog, milestone, board. Lesson: Agile in one page.

Squash

Combining several commits into one, usually when merging a branch, so that main gets one clean commit per merge request.

Example: Ben's nine "wip" commits become one commit, "feat: add difficulty filter (#21)", when Dev merges with squash enabled.

Related: merge, rewriting history, merge request. Lesson: Merging.

SSH key

A pair of files, one private and one public, that proves who you are to a server without sending a password.

You keep the private half on your computer and upload the public half to GitLab or GitHub. Pushing over SSH then needs no token and no password prompt.

Example: Ana generates a key on her laptop, adds the public half to her account, and git push stops asking for anything.

Related: token, deploy key, push. Lesson: SSH keys.

Staged

A change that has been added to the staging area with git add and will be part of the next commit.

git status lists staged changes under "Changes to be committed" in green. A file can be both staged and modified at the same time if you edit it again after staging.

Example: Ana runs git add README.md; the README change is now staged, while her unfinished edit to docs/faq.md is not.

Related: staging area, modified, commit. Lesson: Staging with git add.

Staging area (also: index)

The waiting room between your edited files and a commit: you choose which changes go into the next snapshot.

Editing a file changes only your working tree. git add copies the change into the staging area; git commit turns everything in the staging area into a commit. This extra step lets you commit part of your work, or review exactly what you are about to save. Git's older name for it is "the index".

Example: Ana changed three files but only two belong together; she stages those two, commits, then stages and commits the third separately.

Related: working tree, staged, commit. Lesson: The four areas.

Stash

A local place to park uncommitted changes so you can switch branches or pull, and get them back afterwards with git stash pop.

Stashes never leave your computer; for work that lasts more than a few hours, commit on a branch instead.

Example: Ana stashes her half-written paragraph, checks main for Dev, and pops it back four minutes later.

Related: working tree, branch. Lesson: Stash: parking work.

Status check

A result reported by automation against a commit, shown on the merge or pull request, and optionally required before merging.

A check that merely reports is advice; a check the branch rules require is a reviewer, and the merge button stays locked until it passes. Which is which is a branch setting, not a pipeline setting.

Example: The Markdown linter blocks the merge; the spell checker only reports, because it was added last week.

Submodule

Another Git repository nested inside this one, pinned to a specific commit.

The parent records only which commit the submodule points at, not its files, so a change inside a submodule shows in the parent as a single "Subproject commit" line. A plain clone leaves the folder empty until git submodule update --init --recursive fills it.

Example: The shared style files live in a submodule, which is why the folder was empty after Ana's first clone.

Related: repository, clone, commit. Lesson: Monorepos, LFS, submodules.

Tag

A permanent name for one commit, such as v1.2.0; unlike a branch, it never moves.

Tags mark releases; platforms attach release notes and artifacts to them.

Example: git tag v1.2.0 names the commit that became release 1.2.0.

Related: release, version, ref. Lesson: Tags, releases, semantic versioning.

Team

A named group of people inside a GitHub organization, given a role on repositories so access is managed once rather than person by person.

Teams can contain other teams, and a child team inherits its parent's access. Mentioning a team notifies everyone in it, and a team can be named as a required reviewer.

Example: The docs team has Write on trailguide, so every writer who joins gets it automatically.

Terminal

The window where you type commands and read their text output; on macOS it is the Terminal app, on Windows usually Git Bash or PowerShell.

Everything Git can do is available in the terminal, and error messages appear there in full. IDEs include a terminal panel so you can mix buttons and commands.

Example: Chloe opens the terminal in VS Code, types git status, and reads that two files are modified.

Related: ide, shell, git. Lesson: The terminal for humans.

Access token

A long generated string used instead of your password to let a program act on your behalf, limited to what you allowed and usually with an expiry date.

Git over HTTPS uses one in place of a password. Tokens can be scoped to a few permissions and, on GitHub, to specific repositories, which is what makes them safer than a password.

Example: Ana's fine-grained token can read and write one repository and stops working in ninety days.

Tracked

A file Git already knows about because it was in a previous commit or has been staged.

Git watches tracked files for changes and reports them in git status. A brand-new file is untracked until you git add it for the first time.

Example: README.md is tracked, so when Ana edits it Git says "modified"; her new notes.txt is untracked, so Git only says it exists.

Related: untracked, modified, staged. Lesson: File states.

Tracking branch (upstream)

A local branch linked to a remote branch, so that git status can report ahead/behind and git pull and git push know where to go.

main tracks origin/main after a clone; a new branch is linked by its first git push -u origin <branch>.

Example: branch 'main' set up to track 'origin/main' after the first push.

Two-factor authentication (2FA)

Signing in with something you know and something you have: a password plus a code from your phone or a security key.

Both platforms require it of contributors. Once it is on, a password alone no longer works anywhere, including for Git, which is why pushing needs a token or an SSH key.

Example: Chloe's sign-in asks for a six-digit code from her phone after her password.

Untracked

A file in your folder that Git has never been told about: it is not in any commit and not staged.

git status lists untracked files at the bottom. They are never committed by accident unless you run git add ., which stages everything, so check the list first. If a file should stay untracked forever, add it to .gitignore.

Example: Ana creates CONTRIBUTING.md; until she runs git add CONTRIBUTING.md, Git shows it under "Untracked files".

Related: tracked, ignored, gitignore. Lesson: File states.

Upstream

Either the remote branch a local branch tracks (its "upstream"), or, in open source, the original project a fork was made from.

The context tells which: git push -u sets the first kind; a second remote named upstream is the second.

Example: git branch --set-upstream-to=origin/main links a branch; git remote add upstream <url> adds the original project to a fork.

Related: tracking branch, fork, remote. Lesson: HEAD, refs, origin, upstream.

Version

A label that identifies one exact state of the software, usually three numbers such as 2.4.1 (breaking changes, features, fixes).

In Git a version is a tag on a commit; on the platform it becomes a release.

Example: 2.4.1 fixes something in 2.4.0 without adding features.

Version control

A system that records every change to a set of files so you can see who changed what and when, go back to any earlier version, and work in parallel with other people.

Git is the most widely used version-control system. Without it, teams end up with report_final_v2_REAL.docx and overwrite each other's work.

Example: Six months after a change, Dev can still see exactly which line Ana changed in the installation guide and why.

Related: git, commit, repository. Lesson: Why version control exists.

Workflow (GitHub Actions)

An automated process defined by a YAML file in .github/workflows/, made of jobs that run when something happens in the repository.

The GitHub equivalent of a GitLab pipeline. A workflow runs on an event such as a push or a pull request; each job runs on a runner and contains steps.

Example: The ci workflow runs the tests and the Markdown linter on every pull request.

Related: pipeline, action, ci. Lesson: GitHub Actions.

Working tree (also: working directory)

The actual files and folders you see and edit on your disk, inside the repository folder.

The working tree is what your editor opens. Git compares it with the staging area and the last commit to tell you what changed. Edits here are not saved in Git until you stage and commit them.

Example: Ana opens trailguide/docs/faq.md in VS Code and types a new answer; that change exists only in her working tree until she commits.

Related: staging area, repository, modified. Lesson: The four areas.