5  Version Control with Git

You’ve been writing and rendering Quarto documents, creating professional reports from code and data. But what happens when you want to go back to yesterday’s version? Or try a completely different structure without losing what you have? Every engineer eventually faces a moment of dread: you made changes to a working document or project, and now something is broken. You desperately wish you could go back to the version from before that last edit. This is the problem that version control solves.

Git is a version control system that tracks changes to files over time. Think of it as an infinitely powerful “undo” system combined with a detailed logbook of every modification ever made to your project. But Git goes far beyond simple backups. It enables you to experiment fearlessly, collaborate with teammates without overwriting each other’s work, and maintain a complete, searchable history of how your project evolved.

Git was created in 2005 by Linus Torvalds to manage the Linux kernel, one of the largest collaborative software projects in history. The tool was designed for speed, data integrity, and supporting distributed, non-linear workflows. These design principles make Git equally valuable for a solo engineer tracking changes to a simulation model or a team collaborating on a production system.

5.1 Why Not Just Use Google Docs?

You’re probably familiar with Google Docs and its automatic saving feature. Every keystroke is saved to the cloud, and you can see a version history showing how the document evolved. This works wonderfully for prose documents like essays, reports, and meeting notes. So why do we need Git?

The answer lies in the nature of what we’re tracking. Google Docs excels at collaborative prose writing where changes flow continuously and merge naturally. If two people edit different paragraphs simultaneously, Google Docs handles it seamlessly. The autosave feature means you never lose work, and the version history lets you see how the document evolved.

But consider what happens with code and technical projects beyond prose documents. Code is not prose. A single misplaced character can break an entire program. Changes to one file often depend on changes to other files. You need to test changes before committing to them. And you frequently need to work on experimental features without risking your stable, working version. Even for documents, you need checkpoints that capture working states, not continuous keystroke-by-keystroke autosaves.

Here’s a comparison of the two approaches:

Aspect	Google Docs	Git
Saving	Automatic, continuous	Manual, intentional
History	Every keystroke recorded	Meaningful snapshots you define
Branching	Not supported	Core feature
Offline work	Limited	Full functionality
File types	Documents only	Any file type
Collaboration	Real-time, same document	Asynchronous, merge when ready

Google Docs’ autosave is perfect for prose because you want every word captured as you write. But for code, you want intentional checkpoints. You want to save a version when the code works, not capture every typo and false start along the way. Git gives you this control: you decide when to create a checkpoint (called a “commit”) and what message describes that checkpoint.

The branching capability is equally important. Imagine you have a working report and want to try a completely different organizational structure. In Google Docs, you’d make a copy of the entire document. With Git, you create a “branch,” an independent line of development. If the experiment works, you merge it back. If it fails, you simply delete the branch. Your original remains untouched either way.

5.2 The Git Mental Model

Before diving into commands, let’s build a clear mental model of how Git organizes your work. Understanding this structure will make every Git operation intuitive rather than mysterious.

5.2.1 The Three States

Every file in a Git project exists in one of three states, which correspond to three areas where files live:

1. Working Directory: This is the actual folder on your computer containing your project files. When you edit a file in Zed, you’re modifying the working directory. Git can see these files but hasn’t recorded the changes yet.

2. Staging Area (also called the “Index”): This is a preparation zone where you gather changes before recording them. Think of it as a draft of your next commit. You explicitly choose which changes to stage, giving you precise control over what gets recorded.

3. Repository (the .git directory): This is Git’s database, stored in a hidden .git folder in your project. It contains the complete history of your project: every commit, every version of every file, and all the metadata about who changed what and when.

NoteExercise: Tracking State Changes

You’re editing a Quarto document. After 10 minutes of work, you save the file. Git hasn’t seen any changes yet. You run git add report.qmd. Your colleague asks “Is that document saved now?” What’s technically accurate answer? What happens if your computer crashes right now before you commit?

TipSolution

The code is saved to disk (so a crash won’t lose the edits), but it’s not yet committed to the repository. The file is in the staging area, a preparation zone. If you crash now, the file is safe on disk, but if you were to restore from a backup before the crash, you’d lose these changes because they were never committed. Staging is a middle state: the changes exist on disk but aren’t yet part of your permanent version history. Always commit to make changes permanent.

The basic Git workflow moves changes through these three states:

1. You modify files in your working directory
2. You stage the changes you want to record, adding them to the staging area
3. You commit the staged changes, which permanently stores a snapshot in the repository

WarningSave Your Files!

Git only sees changes that have been saved to disk. If you edit a file in Zed but don’t save it (Ctrl+S or Cmd+S), Git has no idea the file changed. This is different from Google Docs, where every keystroke is automatically saved. Before running any Git command, make sure you’ve saved your files. Zed shows a dot on the tab of unsaved files, so look for that indicator. For more about the disk vs. memory distinction, see Chapter 4.

5.2.2 Commits: The Building Blocks

A commit is a snapshot of your project at a specific moment. Each commit contains the state of every tracked file, a timestamp, the author’s name and email, a message describing the changes, and a unique identifier (a 40-character hash like a1b2c3d4...).

Commits form a chain, with each commit pointing back to its parent (the previous commit). This chain is your project’s history, and you can navigate it to see how your project evolved or to restore previous states.

gitGraph
    commit id: "Initial"
    commit id: "Add intro"
    commit id: "Fix typo"
    commit id: "Add analysis"

Figure 5.1: Commits form a linked chain representing your project’s history

5.3 Your First Git Project

Let’s create a project and track it with Git. We’ll build a technical report using a Quarto document, extending the work you’ve already done in Chapter 3. This example demonstrates Git’s value for the documents you’re writing, and the same workflow applies exactly when we move to code later.

5.3.1 Initializing a Repository

First, create a new directory for your project. Open your terminal (see Chapter 4 if you need a refresher) and navigate to where you want the project to live:

terminal

mkdir quality-report
cd quality-report

Now initialize a Git repository in this directory:

terminal

git init

Git responds with confirmation:

output

Initialized empty Git repository in C:/Users/yourname/quality-report/.git/

This command created a hidden .git directory containing Git’s database. Your project folder looks empty, but Git is now watching it, ready to track changes.

In Zed: You can also open Zed, create a new folder, and then open the terminal panel (Ctrl+` or View → Terminal) to run git init. Zed will automatically detect that the folder is now a Git repository and enable its Git features.

5.3.2 Checking Repository Status

The git status command is your window into Git’s perspective. Run it frequently to understand what’s happening:

terminal

git status

output

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Git tells us we’re on a branch called main (more on branches later), we haven’t made any commits yet, and there’s nothing to commit because we haven’t created any files.

In Zed: The Source Control panel (click the branch icon in the left sidebar, or press Ctrl+Shift+G) shows similar information. It displays changed files, staged files, and lets you perform Git operations with clicks instead of commands.

5.3.3 Creating and Tracking Files

Let’s create our report. In Zed, create a new file (File → New File, or Ctrl+N) and immediately save it as report.qmd in your quality-report folder (File → Save, or Ctrl+S). Add some initial content:

report.qmd

---
title: "Manufacturing Quality Analysis Report"
format: html
---

## Executive Summary

This report analyzes defect rates across three production lines
during Q4 2024.

Save the file (Ctrl+S). This is crucial: Git cannot see your changes until they exist on disk.

Now check the status in your terminal:

terminal

git status

output

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        report.qmd

nothing added to commit but untracked files present (use "git add" to track)

Git sees the new file but labels it as “untracked.” Git doesn’t automatically track every file in your directory. You must explicitly tell Git which files to track. This is a feature, not a limitation. It lets you keep temporary files, large datasets, or sensitive configuration files out of version control.

In Zed: The Source Control panel shows report.md under “Untracked Files”. In the file explorer, the filename may appear in a different color (often green) to indicate it’s new and untracked.

5.3.4 Staging Changes

To start tracking a file and prepare it for your first commit, use git add:

terminal

git add report.qmd

Check the status:

terminal

git status

output

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   report.qmd

The file moved from “untracked” to “changes to be committed.” It’s now in the staging area, ready to be recorded in a commit.

In Zed: You can stage files by clicking the checkbox icon next to the filename in the Source Control panel, or by right-clicking and selecting “Stage File”. The file moves from the “Changes” section to the “Staged Changes” section.

5.3.5 Making Your First Commit

Create a commit with the git commit command. Every commit requires a message describing what changed. Use the -m flag to provide the message inline:

terminal

git commit -m "Start quality analysis report with executive summary"

output

[main (root-commit) a1b2c3d] Start quality analysis report with executive summary
 1 file changed, 9 insertions(+)
 create mode 100644 report.qmd

You’ve made your first commit. Git recorded a snapshot of your project that you can return to at any time.

In Zed: Type your commit message in the text box at the bottom of the Source Control panel, then click “Commit Tracked”. Zed calls the same git commit command behind the scenes.

NoteZed Uses Git, Not the Other Way Around

Here’s an important mental model: Zed is a program that knows how to talk to Git. When you click “Commit Tracked” in Zed, it runs git commit for you. But Git itself has no idea Zed exists. Git is a standalone program that works entirely through files on disk and command-line instructions.

This means you can mix and match: use Zed’s GUI for some operations, the terminal for others, or even a different editor entirely. They all work with the same Git repository because they’re all just interfaces to the same underlying Git program.

If you delete Zed tomorrow, Git still works perfectly from the command line. If Git breaks, Zed’s Source Control panel won’t be able to help you because it depends on Git being available. Understanding this relationship will help you troubleshoot problems: if something isn’t working in Zed’s Git panel, try the command in the terminal to see the actual error message.

5.3.6 The Edit-Stage-Commit Cycle

Now let’s expand our report. Open report.qmd in Zed and add a methodology section:

report.qmd

---
title: "Manufacturing Quality Analysis Report"
format: html
---

## Executive Summary

This report analyzes defect rates across three production lines
during Q4 2024.

## Methodology

Data was collected from automated inspection stations at the end of
each production line. Each item was classified as either conforming
or non-conforming based on dimensional tolerances specified in
engineering drawings.

The inspection process captures the following for each item:

- Timestamp of inspection
- Production line identifier
- Pass/fail status
- Specific defect codes for failures

Save the file (Ctrl+S). Remember, Git only sees saved changes.

Check what Git sees:

terminal

git status

output

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   report.qmd

no changes added to commit (use "git add" and/or "git commit -a")

Git detected that the file changed. To see exactly what changed, use git diff:

terminal

git diff

diff --git a/report.qmd b/report.qmd
index 8a3c2f1..b5d4e2a 100644
--- a/report.md
+++ b/report.md
@@ -4,3 +4,17 @@

 This report analyzes defect rates across three production lines
 during Q4 2024.
+
+## Methodology
+
+Data was collected from automated inspection stations at the end of
+each production line. Each item was classified as either conforming
...

Lines starting with + are additions. Lines starting with - would be deletions. This diff view shows exactly what changed, making review straightforward.

In Zed: Click on a modified file in the Source Control panel to see a side-by-side diff view. Additions appear highlighted in green, deletions in red. This visual diff is often easier to read than the terminal output.

Stage and commit the changes:

terminal

git add report.qmd
git commit -m "Add methodology section describing data collection"

5.3.7 Comparing to Google Docs

Let’s pause and compare what just happened to the Google Docs workflow:

In Google Docs, you would have opened the document, typed the methodology section, and… that’s it. Every keystroke was automatically saved. The version history would show dozens of micro-versions as you typed, backspaced, reworded, and refined.

In Git, you wrote and refined the methodology section in Zed (making as many edits as you wanted), saved the file when satisfied, reviewed the changes with git diff, staged with git add, and committed with a meaningful message.

The Git approach gives you one clean checkpoint with a descriptive message instead of a cluttered history of every keystroke. When you look back at this project’s history in six months, you’ll see “Add methodology section describing data collection” rather than 47 auto-saved versions showing your drafting process.

For prose documents where you want continuous backup, Google Docs’ approach is superior. For code and technical projects where you want meaningful checkpoints of working states, Git’s intentional approach wins.

NoteExercise: Predicting git status Output

You’re working on your report. You make changes to both report.qmd and create a new file references.qmd. You save both files but only run git add report.qmd. Based on what you’ve learned about Git’s three states, what will git status show?

TipSolution

git status will show: - report.qmd under “Changes to be committed” (it’s in the staging area) - references.qmd under “Untracked files” (Git hasn’t been told to track it yet)

Only files you explicitly add with git add move to the staging area. New files start as “untracked” no matter whether they’re saved to disk. The staging area is where you curate what gets committed next.

5.4 Viewing Project History

As you make more commits, you’ll want to review the project’s history. The git log command shows the commit history:

terminal

git log

output

commit b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3 (HEAD -> main)
Author: Your Name <your.email@example.com>
Date:   Mon Jan 15 14:30:00 2025 -0500

    Add methodology section describing data collection

commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
Author: Your Name <your.email@example.com>
Date:   Mon Jan 15 14:00:00 2025 -0500

    Start quality analysis report with executive summary

Each commit shows its unique hash, author, date, and message. The HEAD -> main label indicates where you currently are in the history.

For a more compact view:

terminal

git log --oneline

output

b4c5d6e Add methodology section describing data collection
a1b2c3d Start quality analysis report with executive summary

In Zed: As of writing, Zed does not have a “History” or “Commits” section showing recent commits, but it is in development.

To see what changed in a specific commit:

terminal

git show b4c5d6e

5.5 Undoing Mistakes

Git’s real power emerges when you need to undo mistakes. Let’s explore common scenarios.

5.5.1 Discarding Unsaved Edits (Before Staging)

Suppose you made some changes to report.md that you don’t like and haven’t staged yet. You want to go back to the last committed version.

First, make sure you’ve saved the file. If your changes only exist in Zed’s buffer and haven’t been saved to disk, simply closing the file without saving (or using Edit → Undo repeatedly) will discard them. Git isn’t involved yet.

If you’ve saved the unwanted changes to disk but haven’t staged them:

terminal

git restore report.md

This replaces the file’s contents with the last committed version.

This command permanently discards your changes. Git cannot recover them because they were never committed. Use this carefully.

In Zed: Right-click the file in the Source Control panel and select “Discard Changes.”

5.5.2 Unstaging Changes

Suppose you staged a file but changed your mind. Use git restore --staged to move it back to the working directory:

terminal

git restore --staged report.md

The changes remain in your working directory; they’re just no longer staged for the next commit.

In Zed: Uncheck the staging box next to the staged file, or right-click and select “Unstage File.”

5.5.3 Amending the Last Commit

If you made a commit but forgot to include a change or want to fix the commit message:

terminal

git commit --amend -m "Add methodology section with data collection details"

This replaces the previous commit with a new one containing your staged changes and the new message.

5.5.4 Reverting a Commit

To undo a commit that’s already been made while preserving history, use git revert:

terminal

git revert b4c5d6e

This creates a new commit that undoes the changes from the specified commit. The original commit remains in the history, but its effects are reversed.

In Zed: There is a reverse arrow underneath the Commit box.

5.6 Branching: Parallel Universes for Your Project

Branches are one of Git’s most powerful features. A branch is an independent line of development that diverges from the main project. You can experiment, add sections, or try a different approach on a branch without affecting the stable main version.

5.6.1 The Google Docs Comparison

In Google Docs, if you wanted to try a completely different structure for your report, you’d have to make a copy of the entire document (“Quality Report - Copy” or “Quality Report v2”). You’d then have two separate documents to manage. If you decided you liked the new structure, you’d have to manually reconcile the two versions or abandon one entirely.

With Git branches, you keep a single project but create parallel timelines. The branch is lightweight and merging branches back together is a first-class operation.

5.6.2 Creating and Switching Branches

Let’s say you want to try adding a data visualization section, but you’re not sure it belongs in this report. Create a branch to experiment:

terminal

git branch add-visualizations

Switch to the new branch:

terminal

git switch add-visualizations

Or do both in one command:

terminal

git switch -c add-visualizations

In Zed: Click the branch name in the bottom-left status bar to see a list of branches. You can switch branches or create new ones from this menu.

Now any commits you make will be recorded on this branch, leaving main unchanged.

5.6.3 Working on a Branch

Let’s add a visualizations section to our report on this branch. Open report.qmd in Zed and add the new section:

report.qmd

---
title: "Manufacturing Quality Analysis Report"
format: html
---

## Executive Summary

This report analyzes defect rates across three production lines
during Q4 2024.

## Methodology

Data was collected from automated inspection stations at the end of
each production line. Each item was classified as either conforming
or non-conforming based on dimensional tolerances specified in
engineering drawings.

The inspection process captures the following for each item:

- Timestamp of inspection
- Production line identifier
- Pass/fail status
- Specific defect codes for failures

## Data Visualization

The following charts summarize the key findings:

### Defect Rate by Production Line

Line A showed the lowest defect rate at 2.3%, while Line C had the
highest at 4.7%. Line B fell in the middle at 3.1%.

### Defect Rate Over Time

All three lines showed improvement over the quarter, with the most
significant reduction occurring after the November maintenance cycle.

Save the file, then stage and commit:

terminal

git add report.qmd
git commit -m "Add data visualization section with charts description"

5.6.4 Viewing Branches

See all branches and which one you’re on:

terminal

git branch

output

* add-visualizations
  main

The asterisk indicates your current branch.

In Zed: The current branch name appears in the bottom-left status bar. Click it to see all branches.

5.6.5 Switching Back and Seeing the Difference

Switch back to main:

terminal

git switch main

Open report.qmd and notice the visualization section is gone. It only exists on the add-visualizations branch. Your main branch is exactly as you left it. This is the power of branching: parallel development without interference.

NoteExercise: Predicting Branch Behavior

You have two branches: main and fix-typos. You’re currently on main and have made uncommitted changes to report.qmd. You try to switch to fix-typos using git switch fix-typos. Will the switch succeed? What are the possible outcomes?

TipSolution

Git might refuse to switch if the uncommitted changes conflict with what’s on the other branch. If the uncommitted changes don’t conflict, Git might carry them to the new branch. The safest approach is to always commit your work before switching branches. Your changes exist only locally in the working directory until committed, and Git protects you from switching if it would lose or complicate those changes.

ImportantSave Before Switching Branches

Before switching branches, make sure all your changes are either committed or stashed. If you have unsaved changes in Zed, save them first. If you have uncommitted changes on disk, Git will either carry them to the new branch (if there are no conflicts) or refuse to switch. Get in the habit of committing or stashing your work before switching branches.

5.6.6 Merging Branches

You’ve decided the visualization section is good. Merge it into main:

terminal

git switch main
git merge add-visualizations

output

Updating b4c5d6e..c7d8e9f
Fast-forward
 report.qmd | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

The branch’s commits are now part of main’s history. Open report.qmd and the visualization section is there.

5.6.7 Deleting Merged Branches

After merging, you can delete the branch:

terminal

git branch -d add-visualizations

output

Deleted branch add-visualizations (was c7d8e9f).

5.7 The .gitignore File

Not every file belongs in version control. Large data files, temporary files, and files containing secrets should be excluded. The .gitignore file tells Git which files to ignore.

Create a new file in Zed (File → New File), add the following content, and save it as .gitignore (note the leading dot) in your project root:

.gitignore

# Data files (too large for Git)
*.csv
*.xlsx
data/

# Quarto output
_site/
*_files/
*.html

# Temporary files
*.tmp
*~

# OS-generated files
.DS_Store
Thumbs.db
Desktop.ini

# Editor backup files
*.bak
*.swp

Save the file, then stage and commit:

terminal

git add .gitignore
git commit -m "Add .gitignore for data and temporary files"

From now on, Git ignores files matching these patterns. They won’t appear in git status and can’t be accidentally committed.

TipFinding .gitignore Templates

GitHub maintains a collection of .gitignore templates for various languages and frameworks at github.com/github/gitignore. When we start working with Python, we’ll use a more comprehensive template.

5.8 Best Practices for Commits

Good commits make your project history useful. Here are guidelines that professional developers follow.

5.8.1 Commit Messages

Write clear, descriptive commit messages. The first line should be a brief summary (50 characters or less). If more detail is needed, add a blank line followed by a longer explanation:

output

Add statistical analysis section with defect correlations

Include Pareto analysis of defect types showing that three defect
codes account for 78% of all failures. Add correlation analysis
between temperature and defect rate.

Use imperative mood (“Add section” not “Added section”). Think of the message as completing the sentence “This commit will…”

5.8.2 Commit Size

Make commits that are atomic and focused. Each commit should represent one logical change. If you find yourself writing “and” in your commit message (“Add methodology and fix typo and reorganize introduction”), you should probably make separate commits.

Small, focused commits make it easier to understand history, find when a bug was introduced, and revert specific changes without losing other work.

5.8.3 Commit Frequency

Commit often but meaningfully. A good rule of thumb: commit when you reach a stable state where the document or code is complete and correct. Don’t commit broken work, but also don’t wait until a feature is completely finished.

5.8.4 Save Before Committing

It bears repeating: Git only tracks what’s saved to disk. Develop the habit of saving frequently (Ctrl+S) and always checking git status before committing to make sure Git sees what you expect. Look for the dot indicator on Zed’s file tabs, which shows unsaved changes.

5.9 Zed and Git: A Quick Reference

Here’s a summary of how Zed’s GUI features map to Git commands:

Zed Action	Git Command	Location in Zed
View changes	git status	Source Control panel (Ctrl+Shift+G)
Stage file	git add <file>	Click checkbox next to file
Unstage file	git restore --staged <file>	Unclick checkbox next to staged file
Commit	git commit -m "message"	Enter message, click Commit
View diff	git diff	Click modified file in panel
Discard changes	git restore <file>	Right-click → Discard Changes
Switch branch	git switch <branch>	Click branch name in status bar
View history	git log	History section in panel

Remember: Zed is calling Git for you. If something doesn’t work in the GUI, try the terminal command to see detailed error messages.

5.10 Summary

In this chapter, you learned the fundamentals of version control with Git. You can now track changes to your projects through intentional commits, understand the three-state model (working directory, staging area, repository), use both terminal commands and Zed’s GUI for Git operations, branch and merge to work on features safely, and exclude files with .gitignore. These skills form the foundation for collaborative development with GitHub, which we’ll explore in Chapter 6.

The key insight is that Git gives you control over your project’s history in a way that autosave systems cannot. For prose documents, autosave is often what you want. For code and technical projects, intentional checkpoints with meaningful messages provide a history you can actually use. Start using Git on every project, even personal ones. The discipline of thoughtful commits will serve you throughout your engineering career.

5.11 Glossary

Branch

An independent line of development. Branches let you work on features or experiments without affecting the main codebase.

Commit

A snapshot of your project at a specific point in time. Each commit has a unique identifier, author, timestamp, and message.

Diff

A comparison showing the differences between two versions of a file or set of files.

HEAD

A pointer to the current commit you’re working from. Usually points to the tip of the current branch.

Merge

The process of combining changes from one branch into another.

Repository (Repo)

A Git-tracked project, including all files and the complete history of changes stored in the .git directory.

Staging Area (Index)

A preparation area where you assemble changes before committing them. Gives you control over exactly what goes into each commit.

Working Directory

The actual files on your filesystem that you edit. Changes here are not tracked until staged and committed.

Version Control System (VCS)

Software that tracks changes to files over time, enabling you to recall specific versions, compare changes, and collaborate with others. Git is a distributed VCS.

.gitignore

A file specifying patterns for files that Git should ignore and not track.

5.12 Resources

• Pro Git Book: The definitive free resource on Git, available online
• Learning Git: A Hands-On and Visual Guide to the Basics of Git: Excellent visual introduction
• Happy Git and GitHub for the useR: Practical guide with great troubleshooting advice
• Git Immersion: Hands-on tutorial walking through Git fundamentals
• Comprehensive Git Tutorial (4 hours): Video course covering Git in depth

5.13 Exercises

5.13.1 Question 5.1

What are the three states/areas that files move through in Git?

1. Draft, Review, Published
   
2. Working Directory, Staging Area, Repository
   
3. Local, Remote, Cloud
   
4. Created, Modified, Deleted

5.13.2 Question 5.2

What does the git init command do?

1. Downloads a repository from GitHub
   
2. Creates a new Git repository in the current directory
   
3. Commits all changes to the repository
   
4. Pushes changes to a remote server

5.13.3 Question 5.3

What does the git add command do?

1. Creates a new file in the project
   
2. Moves changes from the working directory to the staging area
   
3. Commits changes to the repository
   
4. Pushes changes to GitHub

5.13.4 Question 5.4

What is a commit in Git?

1. A promise to finish a feature
   
2. A snapshot of your project at a specific point in time
   
3. A request to merge branches
   
4. A connection to a remote repository

5.13.5 Question 5.5

Why does Git require manual commits instead of autosaving like Google Docs?

1. Git was created before autosave technology existed
   
2. Autosave would use too much disk space
   
3. Code requires intentional checkpoints of working states, not every keystroke
   
4. Git cannot detect when files change

5.13.6 Question 5.6

What is the purpose of a branch in Git?

1. To permanently delete unwanted files
   
2. To create an independent line of development without affecting main
   
3. To connect to a remote repository
   
4. To compress the repository for storage

5.13.7 Question 5.7

What does the .gitignore file do?

1. Hides the Git repository from other users
   
2. Specifies files that Git should not track
   
3. Lists all commits in the repository
   
4. Encrypts sensitive files in the repository

5.13.8 Question 5.8

True or False: Git can only track changes that have been saved to disk.

1. True
   
2. False

5.13.9 Question 5.9

What command shows the current status of your Git repository, including staged and unstaged changes?

1. git log
   
2. git diff
   
3. git status
   
4. git show

5.13.10 Question 5.10

What does git commit -m "message" do?

1. Sends your changes to GitHub
   
2. Creates a snapshot with the provided description
   
3. Merges two branches together
   
4. Reverts to a previous version