Version control with Git. If you have ever overwritten a file, lost hours of work, or struggled to remember which version of a document is the final one, you already understand the problem Git solves. For the 200-901 exam, you need to know how Git organises collaboration so that multiple people can work on the same project without breaking each other’s changes.
Jump to a section
A simple way to picture Version Control with Git
2 chefs are working on a single recipe for a complex birthday cake. Chef A adds a layer of chocolate ganache to the recipe book, writing 'add 200g dark chocolate after the sponge cools'. At the exact same moment, Chef B writes 'fold in 100ml double cream after the sponge cools' on the very same line. The next day, the kitchen has two separate copies of the recipe, and nobody knows which instruction is correct. The cake is ruined.
Version control with Git is the digital cookbook that solves this mess. Every chef gets their own copy of the entire recipe book. Chef A writes her change on her copy, and Chef B writes his change on his copy. The cookbook system then shows both changes side by side and asks the head chef to decide: 'Do we want ganache, cream, or both?' That decision becomes a new, official version of the recipe. Every previous version remains saved in the book, so if the head chef changes their mind later, they can flip back to the original instructions.
The key detail: the cookbook numbers every version (v1, v2, v3) and records who made each change and when. If Chef B accidentally deletes the 'preheat oven to 180°C' step, the cookbook does not permanently lose that instruction — it simply reverts to v2, and the step reappears. This is exactly how Git tracks every line of code, who changed it, and when, so that no work is ever truly lost.
Git is a version control system. A version control system is a tool that records changes to a set of files over time so that you can recall specific versions later. Think of it as the 'undo' button for entire projects, but much more powerful. Git keeps a complete history of every change ever made, who made it, and why.
Before Git, teams often used shared folders, email attachments with filenames like 'report_final_v3_actuallyfinal.docx', or file servers with one person locking a file so nobody else could edit it. All of these approaches break down fast when multiple people need to work on the same project simultaneously. Git replaces all of that with a structured system that allows parallel work and safe merging.
Here is how Git works at a high level. When you start tracking a project with Git, you create a repository. A repository is simply a folder that Git is watching. Git stores your project files and the entire history of changes to those files inside a hidden directory called '.git'.
Every time you make a change that you want to save, you perform a commit. A commit is like taking a snapshot of your entire project at that moment. Each commit gets a unique identifier, which is a long string of hexadecimal numbers called a SHA-1 hash. The commit also stores the author's name, the date, and a message you write to describe what changed.
Git does not store a full copy of every file in every commit. Instead, it stores snapshots of the changes. If you only changed one line in one file, Git saves only that change, plus a pointer to the unchanged files from the previous commit. This makes Git incredibly efficient.
A branch in Git is a separate line of development. Imagine the main version of your project as the trunk of a tree. When you want to experiment with a new feature, you create a branch, which is like a new branch growing off the trunk. You can work on your branch without affecting the main trunk. Other people can work on their own branches simultaneously. Later, you can merge your branch back into the main trunk. Merging is the process of taking the changes from one branch and applying them to another.
Git supports several workflows that teams use to collaborate. A workflow is just a set of rules about how and when to create branches and merge them. The most common workflows include:
Git Flow: Uses two main branches (master and develop) plus feature branches, release branches, and hotfix branches. This is structured but complex.
GitHub Flow: Uses a single main branch with feature branches that are merged via pull requests. Simpler and popular for continuous delivery.
GitLab Flow: Adds environment branches (staging, production) for more control over deployments.
When merging, Git automatically combines changes most of the time. However, if two people changed the same line in the same file in different ways, Git cannot decide which version is correct. This is called a merge conflict. Git marks the conflicting area in the file and asks a human to resolve it manually by picking one version or writing a new one.
Git also supports collaboration through remote repositories. A remote repository is a copy of your project hosted on a server, like GitHub or GitLab. You can push your commits to the remote so others can see them, and pull their commits to your local machine. This is how distributed teams work together without emailing files.
Why does all this matter for the exam? The DevNet Associate exam expects you to understand the difference between centralised and distributed version control, the concept of branches and merging, and common workflows. You will not need to memorise every Git command, but you must be able to read a Git log, understand what a commit is, and explain why branching is important for collaboration.
Initialise a Repository
You run 'git init' in your project folder, which creates a hidden '.git' directory. This directory is the heart of version control — it will store all your commits, branches, and history. Without this step, Git does not track any changes in your folder.
Stage Changes
After editing a file, you use 'git add <filename>' to move those changes to the staging area. This is like putting items into a box before sealing it. The staging area lets you decide which changes belong in the next commit, so you can commit related changes together.
Commit the Snapshot
You run 'git commit -m "your message"' to permanently save the staged changes as a new snapshot in the repository's history. Each commit has a unique ID and stores who made the change, when, and why. A good commit message is short but descriptive, like 'add user login form'.
Create a Branch
You run 'git branch my-feature' to create a new branch, then 'git checkout my-feature' or 'git switch my-feature' to start working on it. This creates a separate line of development where you can experiment without affecting the main code. Other team members can work on their own branches simultaneously.
Merge a Branch
Once your feature is complete and tested, you switch back to the target branch (usually 'main') and run 'git merge my-feature'. Git combines the changes from your feature branch into the target branch. If changes conflict, Git pauses the merge and asks you to resolve the conflict manually.
Push to Remote
You run 'git push origin main' to upload your commits to the remote repository (for example, on GitHub). This makes your changes available to the rest of the team. They can now pull the latest version and see your work.
Imagine you work at a mid-sized software company that builds a customer web application. Your team has 6 developers: Alice, Bob, Carlos, Diana, Edward, and you. The application is currently live, serving real customers. You need to add a new payment feature while Bob fixes a critical bug in the login system, and Carlos experiments with a new search algorithm.
Without Git, this would be chaos. Everyone would need to take turns editing the same files, and any mistake could break the live site. With Git, you all work on your own branches.
Here is exactly how it plays out:
First, you each clone the remote repository from the company's GitHub server. Cloning means downloading the entire project and its history to your local machine. You now have your own complete copy.
You create a feature branch called 'payment-integration' from the main branch. Bob creates a hotfix branch called 'login-bugfix'. Carlos creates a feature branch called 'search-experiment'. All three branches are based on the same point in history, but each developer works independently.
You code the payment feature, making commits as you go. Each commit has a message like 'add payment form validation' or 'connect to Stripe API'. Bob fixes the login bug in a single commit. Carlos works for three days on his search code.
Bob finishes first. He pushes his hotfix branch to the remote, creates a pull request, and after code review, his branch is merged into the main branch. The main branch now includes the bug fix. Your branch does not include Bob's fix yet, but that is fine — you will pull the latest main branch into your own branch later.
When you finish your payment feature, you also push your branch and create a pull request. Your teammates review your code, spot a potential security issue, and ask you to fix it. You make the change, commit it, and update the pull request. Once approved, your branch is merged into main.
Carlos's experiment is not finished and is not stable, so his branch stays open. He continues working. The main branch remains stable and deployable at all times because only reviewed code is merged.
This workflow is called the 'feature branch workflow'. It is the foundation of most modern Git workflows. The specific tools used in this scenario include:
git clone to download the repository
git checkout -b to create and switch to a new branch
git add and git commit to stage and save changes
git push to upload commits to the remote
git pull to download the latest changes from the remote
Pull requests (or merge requests) for code review before merging
The exam expects you to recognise this process and understand why each step exists.
The 200-901 exam tests version control under objective 3.2: 'Describe Git workflows, branching, merging, and collaboration'. You will not be asked to run Git commands from memory. Instead, the exam presents scenario-based multiple-choice questions that test your conceptual understanding.
Here are the specific concepts the exam loves to test:
The difference between a repository, a commit, a branch, and a tag. A tag is like a bookmark for a specific commit, often used for marking release versions (v1.0, v2.0). The exam expects you to know that a tag does not move forward like a branch does.
The purpose of a merge conflict and how to resolve it. The exam may show you a merge conflict marker (<<<<<<<, =======, >>>>>>>) and ask what it means. The correct answer is that Git encountered conflicting changes and needs human intervention.
The difference between a fast-forward merge and a three-way merge. A fast-forward merge happens when the target branch has not diverged; Git simply moves the pointer forward. A three-way merge creates a new commit that combines two divergent branches.
Which workflow is appropriate for a given scenario. The exam may describe a small team doing continuous deployment (GitHub Flow is best) versus a large team with strict release cycles (Git Flow is better).
The role of a remote repository. A remote is not a backup — it is a central point for collaboration. You must understand push, pull, and fetch operations. Fetch downloads new data without integrating it; pull downloads and integrates.
Common traps the exam sets:
Confusing 'pull' with 'fetch'. A trap question describes a developer who wants to see what colleagues have changed without merging. The correct answer is 'fetch', not 'pull'.
Believing that Git stores full copies of every file in every commit. The exam will offer a distractor that says 'Git stores complete snapshots of all files each commit'. The truth is Git stores snapshots of changes, not full copies, although it does store the entire file if it changed.
Thinking that a branch is a copy of the files. A branch is just a pointer to a specific commit. The exam may test this with a question about creating multiple branches — only the pointer data is created, not duplicated files.
Key definitions to memorise:
Repository: the folder containing your project and the .git directory that holds the history.
Commit: a snapshot of the project at a point in time, with a unique SHA-1 hash.
Branch: a movable pointer to a commit, allowing parallel development.
Merge: combining changes from one branch into another.
Merge conflict: when two branches changed the same part of the same file, requiring manual resolution.
Clone: downloading a remote repository to your local machine.
Push: sending your local commits to a remote repository.
Pull: fetching changes from a remote and merging them into your local branch.
Remote: a copy of the repository hosted on a server (like GitHub, GitLab, or Bitbucket).
Working directory: the files you can see and edit on your computer.
Staging area: an intermediate area where you prepare changes before committing them.
The exam will also expect you to recognise the basic Git commands for each action, even if you do not memorise every flag. For example, 'git add' stages a change, 'git commit' saves it, 'git branch' lists or creates branches, and 'git merge' combines branches.
Git is a distributed version control system that tracks changes to files and allows multiple developers to collaborate without overwriting each other's work.
A commit is a snapshot of your entire project at a specific moment, identified by a unique SHA-1 hash and containing the author, date, and description of the change.
A branch is a lightweight, movable pointer to a specific commit that enables parallel development of features, bug fixes, or experiments.
A merge conflict occurs when two branches modify the same line of the same file in different ways, requiring a human to manually resolve the inconsistency.
A remote repository is a shared copy of your project hosted on a server (like GitHub or GitLab) that allows team members to push and pull changes.
The three most common Git workflows for the exam are Git Flow, GitHub Flow, and GitLab Flow, each suited to different release strategies and team sizes.
The staging area (also called the index) lets you choose exactly which changes to include in your next commit, giving you fine-grained control over project history.
Git does not store full copies of every file in every commit; it stores compressed snapshots of the differences between versions, making it efficient in disk usage.
These come up on the exam all the time. Here's how to tell them apart.
Git
Version control software that runs locally on your machine
Does not require an internet connection to function
Manages commits, branches, and merges through command-line or GUI clients
GitHub
Cloud platform that hosts Git repositories online
Requires an internet connection to push and pull changes
Adds web-based features like pull requests, code review, and issue tracking
Commit
A permanent snapshot of the entire project at a single point in time
Has a unique SHA-1 hash that identifies it
Cannot be moved or changed after creation
Branch
A movable pointer that refers to a specific commit
Can be created, deleted, and moved to point to different commits
Allows parallel lines of development
Merge
Combines two branches by creating a new merge commit
Preserves the exact history of both branches
Safer for shared branches because it does not rewrite history
Rebase
Moves the entire feature branch to start from the tip of the target branch
Rewrites commit history by creating new commits for each original commit
Creates a linear history but can cause issues if used on shared branches
Pull
Downloads new commits from remote AND merges them into your current branch
Automatically updates your working directory if no conflicts occur
Combines two steps: fetch followed by merge
Fetch
Downloads new commits from remote without merging them
Leaves your working directory unchanged
Lets you review changes before deciding to integrate them manually
Mistake
Git is the same as GitHub. They are the same product used for storing code.
Correct
Git is the version control software that runs on your local machine. GitHub is a cloud-based platform that hosts Git repositories and adds collaboration features like pull requests and issue tracking.
Because beginners often first encounter Git through GitHub's web interface, they assume the name 'GitHub' is just the full name of the tool.
Mistake
When you commit a change, Git saves a full copy of every file in the project, so the repository grows huge with every commit.
Correct
Git stores snapshots of the changes (diffs) rather than full copies of all files. Only files that actually changed get a new snapshot; unchanged files are linked to the previous version.
This misconception comes from thinking of 'save' like a traditional file save that overwrites the whole file, rather than Git's change-based storage model.
Mistake
Once you merge a branch, the branch disappears or is deleted automatically by Git.
Correct
Merging does not delete the branch. The branch remains in the repository as a label pointing to its last commit. You can keep using it, delete it manually, or leave it. GitHub and GitLab often encourage deleting merged branches, but that is a team policy, not a Git requirement.
Because in many web interfaces, the merged branch visually vanishes after the merge, leading beginners to think Git removes it.
Mistake
A merge conflict means something went wrong and the code is corrupted.
Correct
A merge conflict is a normal, expected event in collaborative development. It simply means Git cannot automatically decide which change to keep. The conflict must be resolved manually by a developer, after which the merge proceeds normally.
The word 'conflict' sounds negative, and beginners associate it with errors or crashes, not with routine workflow.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Git is the version control software that runs on your computer and tracks changes to files. GitHub is a website that hosts copies of Git repositories and adds web-based features like pull requests, issue tracking, and code review.
A commit saves all the changes you have staged as a permanent snapshot in the repository's history. Each commit gets a unique identifier (a SHA-1 hash) and stores the author, timestamp, and a description message.
A merge conflict happens when two branches change the same line of the same file in different ways. Git stops the merge and marks the conflict in the file with special markers. You must edit the file to decide which version to keep, then save and commit the resolution.
Git pull downloads new commits from a remote repository and immediately merges them into your current branch. Git fetch downloads the new commits but does not merge them, giving you a chance to review changes before integrating them.
If the commit is local and has not been pushed, you can use 'git reset --soft HEAD~1' to undo the commit while keeping the changes in your staging area. If it has been pushed, you typically use 'git revert' to create a new commit that reverses the changes, which is safer for shared repositories.
A branch is a lightweight, movable pointer to a specific commit. It allows you to work on different features or experiments in isolation without affecting the main codebase. You can create, switch, and merge branches easily.
You've finished Version Control with Git. Continue through the 200-901 study guide to build a complete picture of the exam.
Done with this chapter?