Version Control with Git

---

Dark Mode

Show Highlights

Audio Clips

Want to practice? Try the Interactive Git Tutorial — hands-on exercises in a real Linux system right in the browser!

In modern software construction, version control is not just a convenience—it is a foundational practice, solving several major challenges associated with managing code. Git is by far the most common tool for version control. Let’s dive into both!

Basics

What is Version Control?

Version control (also known as source control or revision control) is the software engineering practice of controlling, organizing, and tracking different versions in the history of computer files. While it works best with text-based source code, it can theoretically track any file type.

We call a tool that supports version control a Version Control System (VCS). The most common version control systems are:

• Git (most common for open source systems, also used by Microsoft, Apple, and most other companies)
• Mercurial (used by Meta, formerly Facebook (Goode and Rain 2014), Jane Street, and some others)
• Piper (internal tool used by Google (Potvin and Levenberg 2016))
• Subversion (used by some older projects)

Why is it Essential?

Manual version control—saving files with names like Homework_final_v2_really_final.txt—is cumbersome and error-prone. Automated systems like Git solve several critical problems:

• Collaboration: Multiple developers can work concurrently on the same project without overwriting each other’s changes.
• Change Tracking: Developers can see exactly what has changed since they last worked on a file.
• Traceability: It provides a summary of every modification: who made it, when it happened, and why.
• Reversion/Rollback: If a bug is introduced, you can easily revert to a known stable version.
• Parallel Development: Branching allows for the isolated development of new features or bug fixes without affecting the main codebase.

Centralized vs. Distributed Version Control

There are two primary models of version control systems:

Feature	Centralized (e.g., Subversion, Piper)	Distributed (e.g., Git, Mercurial)
Data Storage	Data is stored in a single central repository.	Each developer has a full copy of the entire repository history.
Offline Work	Requires a connection to the central server to make changes.	Developers can work and commit changes locally while offline.
Best For	Small teams requiring strict centralized control.	Large teams, open-source projects, and distributed workflows.

The Git Architecture: The Three States

To understand Git, you must understand where your files live at any given time. Git operates across three main “states” or areas:

1. Working Directory (or Working Tree): This is where you currently edit your files. It contains the files as they exist on your disk.
2. Staging Area (or Index): This is a middle ground where you “stage” changes you want to include in your next snapshot.
3. Local Repository: This is where Git stores the compressed snapshots (commits) of your project’s history.

Fundamental Git Workflow

A typical Git workflow follows these steps:

1. Initialize: Turn a directory into a Git repo using git init.
2. Stage: Add file contents to the staging area with git add <filename>.
3. Commit: Record the snapshot of the staged changes with git commit -m "message".
4. Check Status: Use git status to see which files are modified, staged, or untracked.
5. Review History: Use git log to see the sequence of past commits.

Inspecting Differences

git diff is used to compare different versions of your code:

• git diff: Compares the working directory to the staging area.
• git diff --staged (also --cached): Compares the staging area to the latest commit — useful to review exactly what you are about to commit.
• git diff HEAD: Compares the working directory to the latest commit.
• git diff HEAD^ HEAD: Compares the parent commit to the latest commit (shows what the latest commit changed).
• git diff main..feature: Shows all changes in feature that are not yet in main — useful for reviewing a branch before merging.

Branching and Merging

A branch in Git is like a pointer to a commit (implemented as a lightweight, 41-byte text file stored in .git/refs/heads/ that contains the SHA checksum of the commit it currently points to). Creating or destroying a branch is nearly instantaneous — Git writes or deletes a tiny reference, not a copy of your project. The HEAD pointer (stored in .git/HEAD) normally holds a symbolic reference to the current branch, such as ref: refs/heads/main.

Integrating Changes

When you want to bring changes from a feature branch back into the main codebase, Git typically uses one of two automatic merge strategies:

• Fast-Forward Merge: When the target branch (main) has received no new commits since the feature branch was created, Git simply advances the main pointer to the tip of the feature branch. No merge commit is created; the history stays perfectly linear. Use git merge --no-ff to force Git to create a merge commit even when a fast-forward is possible — this preserves a record that a feature branch existed.
• Three-Way Merge: When both branches have diverged — each has commits the other doesn’t — Git compares both tips against their common ancestor and creates a new merge commit with two parents. The commit graph forms a diamond shape where the two diverging paths converge.

Alternative Integration Workflows

For more control over your project’s history, you can use these manual techniques:

• Rebasing: Re-applies commits from one branch onto a new base, producing new commit objects with new SHA hashes. Creates a linear history but must never be used on shared branches, as it rewrites history that collaborators may already have.
• Squashing: git merge --squash collapses all commits from a feature branch into a single commit on the target branch, keeping the main history tidy.

Complications

• Merge Conflict: Happens when Git cannot automatically reconcile differences — usually when the same lines of code were changed in both branches. Git marks the conflicting sections directly in the file using conflict markers:

  <<<<<<< HEAD
  your version of the code
  =======
  incoming branch version
  >>>>>>> feature-branch
  

  To resolve: edit the file to keep the correct content (removing all markers), then git add the resolved file and git commit to complete the merge. Use git merge --abort to cancel a merge in progress and return to the pre-merge state.

• Detached HEAD: Occurs when HEAD points directly to a commit hash rather than a branch reference — for example, when using git switch --detach <commit> to inspect an older version of the codebase. New commits made in this state are not anchored to any branch and can easily be lost when switching away. To preserve work from a detached HEAD, create a new branch with git switch -c <name> before switching elsewhere. Use git reflog to recover the hash of any commits made in detached HEAD state.

Advanced Power Tools

Git includes several advanced commands for debugging and project management:

• git stash: Temporarily saves local changes (staged and unstaged) so you can switch branches without committing messy or incomplete work.
• git cherry-pick: Selectively applies a specific commit from one branch onto another.
• git bisect: Uses a binary search through your commit history to find the exact commit that introduced a bug.
• git blame: Annotates each line of a file with the name of the author and the commit hash of the last person to modify it.
• git revert: Safely “undoes” a previous commit by creating a new commit with the inverse changes, preserving the original history.
• git reflog: Records every position HEAD has pointed to, even when you switch branches, reset, or make commits in detached HEAD state. This is your safety net for recovering “lost” commits — if a commit is no longer reachable via any branch, git reflog will show its hash so you can recover it with git switch -c <name> <hash>.

Managing Large Projects: Submodules

For very large projects, Git Submodules allow you to keep one Git repository as a subdirectory of another. This is ideal for including external libraries or shared modules while maintaining their independent history. Internally, a submodule is represented as a file pointing to a specific commit ID in the external repo.

Best Practices for Professional Use

• Write Meaningful Commit Messages: Messages should explain what was changed and why. Avoid vague messages like “bugfix” or “small changes”.
• Commit Small and Often: Aim for small, coherent commits rather than massive, “everything” updates.
• Never Force-Push (git push -f) on Shared Branches: Force-pushing overwrites the remote history to match your local copy, permanently deleting any commits your collaborators have already pushed.
• Use git revert to Undo Shared History: When a bad commit has already been pushed, use git revert <hash> to create a new “anti-commit” that safely inverts the change while preserving the full history. Never use git reset --hard on shared branches — it rewrites history and breaks every collaborator’s local copy.
• Use .gitignore: Always include a .gitignore file to prevent tracking unnecessary or sensitive files. The file uses glob patterns:
  • *.pyc — ignore all files with a given extension.
  • __pycache__/ — ignore an entire directory (trailing slash).
  • .env — ignore a specific file (commonly used to protect secrets and API keys).
  • node_modules/, venv/ — ignore dependency folders.
  • .DS_Store, Thumbs.db — ignore OS-generated clutter files. Note: .gitignore has no retroactive effect — files already tracked by Git must be explicitly removed with git rm --cached <file> before the ignore pattern applies. Commit the .gitignore itself so the whole team benefits.
• Pull Frequently: Regularly pull the latest changes from the main branch to catch merge conflicts early.

Git Command Manual

Common Git commands can be categorized into several functional groups, ranging from basic setup to advanced debugging and collaboration.

Configuration and Initialization

Before working with Git, you must establish your identity and initialize your project.

• git config: Used to set global or repository-specific settings. Common configurations include setting your username, email, and preferred text editor.
• git init: Initializes a new, empty Git repository in your current directory, allowing Git to begin tracking files.

The Core Workflow (Local Changes)

These commands manage the lifecycle of your changes across the three Git states: the working directory, the staging area (index), and the repository history.

• git add: Adds file contents to the staging area to be included in the next commit.
• git status: Provides an overview of which files are currently modified, staged for the next commit, or untracked by Git.
• git commit: Records a snapshot of all changes currently in the staging area and saves it as a new version in the local repository’s history. Professional practice encourages writing meaningful commit messages to help team members understand the “what” and “why” of changes.
• git log: Displays the sequence of past commits. Common flags:
  • git log -p: Shows the actual changes (patches) introduced in each commit.
  • git log --oneline: Displays each commit as a single compact line (short hash + message).
  • git log --graph --all: Renders an ASCII art graph of all branch and merge history.
• git diff: Compares different versions of your project:
  • git diff: Compares the working directory to the staging area.
  • git diff --staged (alias --cached): Compares the staging area to the latest commit.
  • git diff HEAD: Compares the working directory to the latest commit.
  • git diff HEAD^ HEAD: Compares the parent commit to the latest commit (shows what the latest commit changed).
  • git diff main..feature: Shows commits in feature not yet in main.
• git restore (Git 2.23+): The modern command for undoing file changes, replacing the file-restoration uses of the older git checkout and git reset:
  • git restore --staged <file>: Unstages a file, moving it out of the staging area while leaving working directory modifications untouched.
  • git restore <file>: Discards all uncommitted changes to a file in the working directory, restoring it to its last staged or committed state. This is irreversible — uncommitted changes will be permanently lost.

Branching and Merging

Branching allows for parallel development, such as working on a new feature without affecting the main codebase.

• git branch: Lists, creates, or deletes branches. A branch is a lightweight pointer (a 41-byte file in .git/refs/heads/) to a specific commit.
  • git branch -d <branch>: Deletes a branch that has already been merged (safe — Git will refuse if unmerged commits would be lost).
  • git branch -D <branch>: Force-deletes a branch regardless of merge status (use with care).
• git switch (recommended, Git 2.23+): The modern, dedicated command for navigating branches.
  • git switch <branch>: Switches to an existing branch.
  • git switch -c <new-branch>: Creates a new branch and immediately switches to it.
  • git switch --detach <commit>: Checks out an arbitrary commit in detached HEAD state for safely inspecting older code without affecting any branch.
• git checkout (legacy): The older multi-purpose command that handled both branch switching and file restoration. Still widely encountered in documentation and scripts. git checkout <branch> is equivalent to git switch <branch>; git checkout -b <name> is equivalent to git switch -c <name>.
• git merge: Integrates changes from one branch into another.
  • git merge --squash: Combines all commits from a feature branch into a single commit on the target branch to maintain a cleaner history.
  • git merge --no-ff: Forces creation of a merge commit even when a fast-forward would be possible, preserving the record that a feature branch existed.
  • git merge --abort: Cancels an in-progress merge (including one with conflicts) and restores the branch to its pre-merge state.
• git rebase: Re-applies commits from one branch onto a new base. This is often used to create a linear history, though it must never be used on shared branches.

Remote Operations

These commands facilitate collaboration by syncing your local work with a remote server (like GitHub).

• git clone: Creates a local copy of an existing remote repository.
• git remote: Lists remote connections. git remote add origin <url> registers a remote named origin (the conventional primary remote name).
• git pull: Fetches changes from a remote repository and immediately merges them into your current local branch.
• git push: Uploads your local commits to a remote repository. Note: Never use git push -f (force-push) on shared branches, as it can overwrite and destroy work pushed by other team members.
  • git push -u origin <branch>: Pushes the branch and sets up upstream tracking, so future git push and git pull calls on this branch no longer need to specify the remote and branch name.
• Bare Repositories: A bare repository (created with git init --bare) contains only the Git metadata with no working directory — it stores history but you cannot edit files in it directly. Remote servers (GitHub, GitLab, self-hosted) use bare repositories as the central point that all developers push to and pull from.

Advanced and Debugging Tools

Git includes powerful utilities for handling complex scenarios and tracking down bugs.

• git stash / git stash pop: Temporarily saves uncommitted changes (both staged and unstaged) so you can switch contexts without making a messy commit. Use pop to re-apply those changes later.
• git cherry-pick: Selectively applies a single specific commit from one branch onto another.
• git bisect: Uses a binary search through commit history to find the exact commit that introduced a bug.
• git blame: Annotates each line of a file with the author and commit ID of the last person to modify it.
• git revert <commit>: Creates a new “anti-commit” that applies the exact inverse changes of a previous commit, safely undoing it without rewriting history. Prefer this over git reset whenever the commit to undo has already been pushed to a shared branch.
• git reflog: Shows a chronological log of every position HEAD has pointed to in the local repository. Indispensable for recovering “lost” commits — commits made in detached HEAD state or after an accidental reset can be found here and recovered with git switch -c <name> <hash>.
• git show: Displays detailed information about a specific Git object, such as a commit.
• git submodule: Allows you to include an external Git repository as a subdirectory of your project while maintaining its independent history.

Quiz

Git Commands Flashcards

Which Git command would you use for the following scenarios?

You have some uncommitted, incomplete changes in your working directory, but you need to switch to another branch to urgently fix a bug. How do you temporarily save your current work without making a messy commit?

git stash

git stash temporarily shelves your staged and unstaged changes for tracked files. To include brand new, untracked files in the stash, you must use git stash -u.

You know a bug was introduced recently, but you aren’t sure which commit caused it. How do you perform a binary search through your commit history to find the exact commit that broke the code?

git bisect

git bisect systematically halves your commit history, asking you to test if the bug is present at each step, making it highly efficient for tracking down regressions.

You are looking at a file and want to know exactly who last modified a specific line of code, and in which commit they did it.

git blame

git blame annotates each line of a file with the author and the commit hash of the last modification, which is very useful for figuring out who to ask about a piece of code.

You want to safely ‘undo’ a previous commit that introduced an error, but you don’t want to rewrite history or force-push. How do you create a new commit with the exact inverse changes?

git revert

git revert is the safest way to undo changes on a shared branch because it adds a new commit that nullifies the targeted commit, rather than deleting history.

You want to see exactly what has changed in your working directory compared to your last saved snapshot (the most recent commit).

git diff HEAD

Using git diff HEAD compares your current modified tracked files on disk with the most recent commit. Note that it does not show completely untracked files.

You have a feature branch with several experimental commits, but you only want to move one specific, completed commit over to your main branch.

git cherry-pick

git cherry-pick allows you to selectively grab a specific commit from one branch and apply it onto your current branch, without merging the entire branch history.

You want to integrate a feature branch into main, but instead of bringing over all 15 tiny incremental commits, you want them combined into one clean commit on the main branch.

git merge --squash

Squashing combines all the patches from the feature branch into a single set of changes, allowing you to make one clean commit on the target branch and keep the history tidy with git merge --squash.

You are building a massive project and want to include an entirely separate external Git repository as a subdirectory within your project, while keeping its history independent.

git submodule

git submodule allows you to nest an independent repository inside your main project. It essentially creates a pointer to a specific commit of that external library.

You are starting a brand new project in an empty folder on your computer and want Git to start tracking changes in this directory.

git init

This command initializes a new, empty Git repository in the current directory via git init, creating the hidden .git folder that manages all version control data.

You have just installed Git on a new computer and need to set up your username and email address so that your commits are properly attributed to you.

git config

Using git config --global user.name and user.email establishes your default identity, which can be overridden for specific projects using git config --local.

You’ve made changes to three different files, but you only want two of them to be included in your next snapshot. How do you move those specific files to the staging area?

git add <filename>

The git add command moves file modifications from the working directory into the staging area (index) to prepare them for the next commit.

You’ve lost track of what you’ve been doing. You want a quick overview of which files are modified, which are staged, and which are completely untracked by Git.

git status

This command git status provides a high-level summary of the working tree and staging area statuses, making it one of the most frequently used Git commands.

You have staged all the files for a completed feature and are ready to permanently save this snapshot to your local repository’s history with a descriptive message.

git commit -m 'message'

Committing takes everything in the staging area and records it as a permanent new version in your local Git history via git commit.

You want to review the chronological history of all past commits on your current branch, including their author, date, and commit message.

git log

This command git log prints out the commit history. You can also add flags like -p to see the exact patch/diff introduced in each commit.

You’ve made edits to a file but haven’t staged it yet. You want to see the exact lines of code you added or removed compared to what is currently in the staging area.

git diff

Running git diff without any arguments compares your current working directory against the staging area.

You want to start working on a completely new feature in isolation without affecting the main codebase.

git branch <branch-name>

This command git branch creates a new branch pointer at your current commit, allowing you to diverge from the main line of development.

You are currently on your feature branch and need to switch your working directory back to the ‘main’ branch.

git switch main

The modern git switch command navigates between branches, updating your working directory and moving HEAD. The legacy equivalent git checkout main still works and is widely seen in older documentation and scripts.

Your feature branch is complete, and you want to integrate its entire commit history into your current ‘main’ branch.

git merge <branch-name>

Merging with git merge takes the divergent histories of two branches and combines them, often resulting in a new ‘merge commit’ with two parents.

Instead of creating a merge commit, you want to take the commits from your feature branch and re-apply them directly on top of the latest ‘main’ branch to create a clean, linear history.

git rebase main

Rebasing with git rebase rewrites history by moving the base of your current branch to the tip of another, which creates a cleaner history but should be avoided on public/shared branches.

You want to start working on an open-source project hosted on GitHub. How do you download a full local copy of that repository to your machine?

git clone <url>

Cloning with git clone downloads the entire repository, including its full history and all branches, from a remote server to your local disk.

Your team members have uploaded new commits to the shared remote repository. You want to fetch those changes and immediately integrate them into your current local branch.

git pull

The git pull command is effectively a combination of git fetch and git merge (the default) or git rebase (if configured), integrating remote changes into your local branch.

You have finished making several commits locally and want to upload them to the remote GitHub repository so your team can see them.

git push

git push transmits your local commits to the remote server, updating the remote branch to match your local branch.

You have a specific commit hash and want to see detailed information about it, including the commit message, author, and the exact code diff it introduced.

git show <commit-hash>

git show displays the details of a specific Git object, most commonly used to inspect exactly what changed in a single commit.

You want to start working on a new feature in isolation. How do you create a new branch called ‘feature-auth’ and immediately switch to it in a single command?

git switch -c feature-auth

git switch -c creates a new branch and switches to it in one step. The -c flag stands for ‘create’. The legacy equivalent is git checkout -b feature-auth, which you will still encounter in older scripts and documentation.

You accidentally staged a file you didn’t intend to include in your next commit. How do you move it back to the working directory without losing your modifications?

git restore --staged <filename>

git restore --staged unstages a file by copying the version from the last commit back into the staging area, leaving your working directory modifications completely untouched. It is the modern equivalent of the older git reset HEAD <file>.

You made some experimental changes to a file but want to discard them entirely and revert to the version from your last commit.

git restore <filename>

git restore <file> discards unstaged changes in the working directory, reverting it to the staged version (or the last commit if nothing is staged). To explicitly revert to the last commit, use git restore --source=HEAD <file>.

You merge a feature branch into main, and Git performs the merge without creating a new merge commit — it simply moves the ‘main’ pointer forward. What type of merge is this, and when does it occur?

A fast-forward merge — occurs when ‘main’ has no new commits since the feature branch was created.

A fast-forward merge happens when the target branch hasn’t diverged. Git can simply advance its pointer in a straight line to the tip of the incoming branch, keeping the commit history perfectly linear. If both branches have diverged, Git performs a three-way merge and creates a merge commit instead.

You want to safely inspect the codebase at a specific older commit without modifying any branch. How do you do this?

git switch --detach <commit-hash>

git switch --detach places you in ‘detached HEAD’ state, where HEAD points directly to a specific commit rather than a branch. You can look around freely, but any commits made here are not anchored to a branch and can be lost when switching away. Use git switch -c <name> to anchor them to a new branch if needed.

Workout Complete!

Your Score: 0/28

Come back later to improve your recall!

Version Control and Git Quiz

Test your knowledge of core version control concepts, Git architecture, branching strategies, and advanced commands.

Which of the following best describes the core difference between centralized and distributed version control systems (like Git)?

Correct Answer:

Explanation

This defines the distributed model, giving developers offline access to the full project history and the ability to work independently.

What are the three primary local states that a file can reside in within a standard Git workflow?

Correct Answer:

Explanation

Files are edited in the working directory, moved to the staging area to prep for a snapshot, and finally committed to the local repository.

What does the command git diff HEAD compare?

Correct Answer:

Explanation

Adding HEAD tells Git to compare the uncommitted files currently on your disk with the snapshot of the most recent commit.

Which Git command should you NEVER use on a shared branch because it can permanently overwrite and destroy work pushed by other team members?

Correct Answer:

Explanation

Force-pushing overwrites the remote repository’s history to exactly match yours, which will permanently delete any new commits made by your collaborators.

You have some uncommitted, incomplete changes in your working directory, but you need to switch to another branch to urgently fix a bug. Which command is best suited to temporarily save your current work without making a messy commit?

Correct Answer:

Explanation

git stash temporarily shelves your staged and unstaged changes, leaving you with a clean working directory so you can safely switch contexts.

What happens when you enter a ‘Detached HEAD’ state in Git?

Correct Answer:

Explanation

Checking out a specific commit hash detaches HEAD. Any new commits made in this state won’t update a branch pointer and can easily be lost.

Which Git command utilizes a binary search through your commit history to help you pinpoint the exact commit that introduced a bug?

Correct Answer:

Explanation

git bisect systematically halves your commit history, asking you to test if the bug is present at each step, to efficiently find the exact commit that broke the code.

What is the primary purpose of Git Submodules?

Correct Answer:

Explanation

Submodules allow you to nest an independent repository inside your main project, pointing to a specific commit of that external library.

Which of the following are advantages of a Distributed Version Control System (like Git) compared to a Centralized one? (Select all that apply)

Correct Answers:

Explanation

In distributed systems like Git, developers have a full local copy of the repository, allowing for offline work and eliminating the single point of failure found in centralized systems. This makes it ideal for large, distributed teams. However, it does not prevent merge conflicts.

Which of the following represent the core local states (or areas) where files can reside in a standard Git architecture? (Select all that apply)

Correct Answers:

Explanation

The three primary local states in Git’s architecture are the Working Directory (files on disk), the Staging Area (prepped for the next commit), and the Local Repository (the compressed history of commits). The remote server is external, and ‘Detached HEAD’ is a state of the HEAD pointer, not a file area.

Which of the following commands are primarily used to review changes, history, or differences in a Git repository? (Select all that apply)

Correct Answers:

Explanation

git log shows the commit history, git diff shows differences between states or commits, and git show displays details about a specific Git object (like a commit). git push uploads data, and git init creates a new repository.

In which of the following scenarios would using git stash be considered an appropriate and helpful practice? (Select all that apply)

Correct Answers:

Explanation

git stash temporarily shelves your local modifications (both staged and unstaged), leaving you with a clean working directory. This is perfect for quick context switches or pulling updates without committing messy, incomplete work. It is not used for permanent deletion or applying commits (which would be git cherry-pick).

Which of the following are valid methods or strategies for integrating changes from a feature branch back into the main codebase? (Select all that apply)

Correct Answers:

Explanation

Merging, rebasing, and squashing (git merge --squash) are all techniques used to integrate branch histories together. git bisect is a debugging tool for finding bugs, and git blame is used to see who last modified specific lines of code.

A faulty commit was pushed to a shared ‘main’ branch last week and your teammates have already synced it. Why should you use git revert to fix this rather than git reset --hard followed by a force-push?

Correct Answer:

Explanation

git revert is the safe choice on shared branches because it adds a new forward-moving commit that nullifies the targeted commit, without rewriting or destroying history. Using git reset --hard and force-pushing would overwrite the shared history, causing serious disruption for any teammate who has already synced that commit.

When integrating a feature branch into ‘main’, under what condition will Git perform a fast-forward merge rather than creating a three-way merge commit?

Correct Answer:

Explanation

A fast-forward merge occurs when the target branch’s history has not diverged — Git can simply slide its pointer forward to incorporate the changes linearly. If both branches have unique commits since they split, Git must perform a three-way merge using their common ancestor, resulting in a merge commit with two parents.

What does the file .git/HEAD contain when you are checked out on a branch, compared to when you are in a detached HEAD state?

Correct Answer:

Explanation

Normally, .git/HEAD is a symbolic reference like ref: refs/heads/main — a pointer to a branch pointer. When you enter detached HEAD state (e.g., with git switch --detach <hash>), HEAD is disconnected from any branch and contains the raw SHA hash of a specific commit directly. Any commits made in this state are not anchored to a branch and can be lost when switching away.

Arrange the Git commands into the correct order to: create a feature branch, make changes, and integrate them back into main via a merge.

Drag fragments into the answer area in the correct order (some items are distractors that should not be used):

→ Drop here →

Correct order:
git switch -c feature&&git add app.py&&git commit -m 'Add feature'&&git switch main&&git merge feature

Explanation

The workflow is: create and switch to a feature branch (switch -c), stage changes (add), commit them, switch back to main, and merge the feature branch in. git push -f is dangerous on shared branches and is not part of a local merge workflow. git init creates a new repository — irrelevant here.

Arrange the commands to safely stash your work, pull remote changes, and restore your stashed work.

Drag fragments into the answer area in the correct order (some items are distractors that should not be used):

→ Drop here →

Correct order:
git stash&&git pull&&git stash pop

Explanation

git stash saves uncommitted changes temporarily, git pull fetches and merges remote changes onto a clean working directory, and git stash pop re-applies the stashed changes on top. git stash drop would discard the stash without applying it. git reset --hard would destroy all local changes — dangerous!

Arrange the commands to undo a bad commit on a shared branch safely: first identify the commit, then revert it, then push the fix.

Drag fragments into the answer area in the correct order (some items are distractors that should not be used):

→ Drop here →

Correct order:
git log --oneline&&git revert &&git push</code> </span> </div>

Explanation

git log identifies the bad commit hash. git revert creates a new commit that undoes the bad one — preserving history for all collaborators. git push shares the fix. The distractors (reset --hard + push -f) would rewrite shared history, destroying teammates’ work. Always use revert on shared branches, never reset --hard + force-push.

</div>

Arrange the commands to initialize a new repository and record an initial commit.

Drag fragments into the answer area in the correct order (some items are distractors that should not be used):

→ Drop here →

Correct order:
git init&&git add .&&git commit -m 'Initial commit'

Explanation

git init creates the repository, git add . stages every file in the working directory, and git commit records the first snapshot. git clone copies an existing remote repo — it doesn’t create one from scratch. git push requires a remote to already exist.

Arrange the commands to register a remote called origin and push the main branch to it for the first time.

Drag fragments into the answer area in the correct order (some items are distractors that should not be used):

→ Drop here →

Correct order:
git remote add origin &&git push -u origin main</code> </span> </div>

Explanation

git remote add origin <url> registers the remote address under the alias origin. git push -u origin main uploads the branch and sets the upstream tracking reference so future git push/git pull calls need no extra arguments. git fetch and git pull download data — they don’t publish your local branch.

</div>

Arrange the commands to stage a forgotten file and fold it into the last commit without changing the commit message.

Drag fragments into the answer area in the correct order (some items are distractors that should not be used):

→ Drop here →

Correct order:
git add forgotten.py&&git commit --amend --no-edit

Explanation

git add forgotten.py stages the missing file, and git commit --amend --no-edit rewrites the previous commit to include it while keeping the original message. git reset --hard HEAD~1 would destroy the previous commit entirely. Creating a brand-new commit (-m 'Add forgotten file') is valid but pollutes history with a fixup commit — amend is cleaner when the previous commit hasn’t been pushed.

</div>

Workout Complete!

Your Score: 0/22

</div>

---

References

1. (Goode and Rain 2014): Durham Goode and Rain (2014) “Scaling Mercurial at Facebook.” Engineering at Meta.
2. (Potvin and Levenberg 2016): Rachel Potvin and Josh Levenberg (2016) “Why Google Stores Billions of Lines of Code in a Single Repository,” Communications of the ACM, 59(7), pp. 78–87.