Recommended resources
The freely available resources this lesson will direct you to.
Hello! Last time, you opened gis-shell-lab in VS Code, ran clinic_preview.py, and viewed map_preview.html in a browser. Those files are a useful starting point for Git: you can now see how Git notices a new project and reports edits to a file.
Today you’ll create a local Git repository and use git status and git diff to answer two questions: Which files have changed? and What changed inside them? This is the beginning of version control for the GIS projects you’ll build later. Allow about 35–40 minutes, including the short videos and hands-on steps.
Get Git ready in your workspace
Git records versions of project files on your computer. GitHub is a separate service for hosting and sharing repositories; you do not need a GitHub account today.
Watch Kevin Stratvert’s Git and GitHub Tutorial for Beginners for the purpose of Git, Windows setup, and the commands you’re about to use.
Git and GitHub Tutorial for Beginners
Kevin Stratvert introduces Git and demonstrates turning an existing folder into a repository. Watch for the distinction between installing Git and initializing one particular project.
Watch Git setup for version control, installation, and author settings. Then watch repository creation and first status. He uses Git Bash, but the Git commands shown also work in your VS Code PowerShell terminal.
Open gis-shell-lab in VS Code. If you used gis-shell-lab-2 in the previous lesson, use that folder instead. Open the integrated PowerShell terminal and check both your location and Git installation:
Get-Location
Get-ChildItem
git --version
Your location should end in the workspace folder, and the listing should include clinic_preview.py. If git is not recognised, install Git for Windows from the official Git download site mentioned in the video, then restart VS Code and try git --version in a new terminal. You can continue using PowerShell; you do not have to switch to Git Bash.
Before making the first recorded version of a file, Git needs a name and email for its author. Check whether they are already configured:
git config --global user.name
git config --global user.email
If either command prints nothing, set that value, replacing the examples with your own name and an email address you control:
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
Use your real chosen details rather than the literal examples. You’ll make one small initial checkpoint later in this lesson so that git diff has an earlier file version to compare against.
Initialize and inspect the repository
With the terminal inside your workspace folder, run:
git init
git status
git init creates a hidden .git directory inside this folder. That directory holds Git’s repository information; do not edit or delete it manually. Your Python and HTML files remain where they were. You can confirm that .git exists with:
Get-ChildItem -Force
The first git status will likely say “No commits yet” and list clinic_preview.py and map_preview.html as untracked files. Your branch may be called main or master; either is fine here. Some folders may not appear: Git reports files, not empty directories.
Pro Git explains how to read the status report. Its example begins with an existing repository, whereas yours has just been initialized.
Recording Changes to the Repository
Read the “Checking the Status of Your Files” subsection of the Git book to learn what git status reports.
Start at the paragraph beginning “The main tool you use to determine which files are in which state” and read the status explanation through its description of a clean working directory. Focus on the difference between a tracked file with no edits and an untracked file. Your new repository will not yet show the clean result in the book’s example.
Untracked does not mean Git cannot see a file. It means Git has not been told to include that file in a recorded version. Initializing a folder does not automatically record everything already inside it.
For now, concentrate on the left side of the diagram and the distinction between unmodified and modified. We’ll work deliberately with the staged state in the next lesson.
Give git diff a starting version
Try this command now:
git diff
It will probably print nothing. That is expected. Your existing files are still untracked, so Git has no recorded version of clinic_preview.py against which to show its edits. An empty diff does not mean the folder contains no files.
To make an ordinary edit visible to git diff, we need one starting version. We’ll briefly use two commands that the next lesson will explain in depth. Select only the small Python script—not the entire workspace—and record its current saved contents:
git add .\clinic_preview.py
git commit -m "Add clinic preview starter"
git status
If the commit stops and asks you to set user.name or user.email, return to the configuration commands above, then retry the commit command. If you have made additional changes to the Python file in VS Code, save it with Ctrl+S before running these commands.
Watch the next part of Kevin Stratvert’s tutorial to see how a recorded version makes later differences visible.
Git and GitHub Tutorial for Beginners
Return to Git and GitHub Tutorial for Beginners for a short demonstration of a checkpoint and a subsequent file edit.
Watch the checkpoint to see what the commit records. Then watch the diff, focusing on how git status identifies the edited file while git diff reveals the changed text.
Your latest git status may still list map_preview.html or other files as untracked. That is intentional: you selected only clinic_preview.py. This first commit supplies a comparison point for the exercise below; it is not a request to add every project file.
See exactly what an edit changed
Open clinic_preview.py in VS Code. In the original script, its second line was:
print("Workspace ready for a future web map.")
Change just that line to:
print("Workspace ready for a future interactive web map.")
Save with Ctrl+S, then return to the PowerShell terminal:
git status
git diff
git status should list clinic_preview.py under “Changes not staged for commit” as modified. It tells you which file changed. git diff shows which lines changed. The relevant part of your output should resemble this:
--- a/clinic_preview.py
+++ b/clinic_preview.py
@@ -1,2 +1,2 @@
print("Clinic locations: Pune")
-print("Workspace ready for a future web map.")
+print("Workspace ready for a future interactive web map.")
Your city may differ from Pune; that unchanged line is shown merely for context. In the changed lines, - marks text from the earlier version and + marks the text now in your saved file. The --- and +++ lines above are file labels, not deleted or added lines of code. The @@ line locates the changed portion; you do not need to memorize its numbers yet.
The Git book makes an important distinction between the file you are editing and the version selected for a future checkpoint.
Recording Changes to the Repository
Read “Viewing Your Staged and Unstaged Changes” to understand why git status and git diff answer different questions.
Begin in the opening paragraph at “you want to know exactly what you changed” and read the diff explanation through the paragraph ending “only changes that are still unstaged.” Focus on what plain git diff compares with what git diff --staged compares. The book’s examples have more staged work than your project currently does.
Plain git diff compares your saved working file with the version Git currently has staged. Since you have not staged this latest edit, it shows the changed line. git diff --staged asks a different question: what has been selected for the next checkpoint compared with the last recorded one? You have selected nothing new, so this command should currently produce no output:
git diff --staged
Likewise, plain git diff will not show the contents of map_preview.html while that file remains untracked. Use git status to notice such files. If a diff opens in a scrollable terminal view, press Q to return to the prompt.
What to carry forward
You have turned your existing VS Code folder into a local Git repository. git init set it up, git status showed which files were untracked or modified, and git diff showed the exact edit to a recorded file. The useful habit is to save your file, check status, then read the diff—especially before deciding what to preserve.
Keep the edited clinic_preview.py as it is. In the next lesson, you’ll use that pending change to learn how to select files with git add, inspect the selected version, and make coherent checkpoints with git commit.