Welcome

Welcome to Workshop 7 of Web Architecture. Up to this point, you have been writing code, saving files, and running servers. But what happens when you make a mistake and need to go back to how the code looked yesterday? Or what happens when you need to collaborate with three other students on the same server.js file?

Without version control, developers usually resort to copying folders and creating files with names like:

This is a recipe for disaster. Today, you are going to learn Git, the industry-standard version control system, and GitHub, the cloud platform where developers store and share their Git projects. You will learn the core terminology, how to track changes using the terminal, and how to manage your code visually using a GUI (Graphical User Interface).

Speaking the Language

Git has a specific vocabulary. Before we start typing commands, you need to understand what these terms mean. Review the table below; these are the building blocks of every software engineering team.

Repository (Repo)

A folder that Git is actively tracking. It contains all your project files and the hidden .git folder containing the entire history of every change ever made.

Commit

A saved "snapshot" of your project at a specific point in time. Every commit requires a brief message explaining what you changed (e.g., "Added EJS templating").

Branch

A parallel universe of your code. You create a branch to work on a new feature safely without breaking the main, working code.

Merge

The process of taking the changes from one branch (e.g., your experimental feature) and combining them back into the main branch.

Remote

A version of your repository hosted on the internet (like on GitHub or UCL's enterprise servers) rather than on your local machine.

Clone

Downloading a complete copy of a remote repository onto your local computer.

Push

Uploading your local commits up to a remote repository so others can see them.

Pull

Downloading the latest commits from a remote repository and merging them into your local files.

Initial Configuration

Before Git allows you to save a snapshot of your code, it needs to know who you are so it can attach your name to the history log.

Open your VS Code integrated terminal (Ctrl+\` or Terminal > New Terminal) and run the following two commands, replacing the placeholders with your actual name and email.

git config --global user.name "Your Full Name"
git config --global user.email "your.email@ucl.ac.uk"

Initializing the Repo

Let's create a brand new web project and put it under version control using the command line. In your terminal, navigate to your main working directory, create a new folder, and step inside it:

cd ~
mkdir git-demo-project
cd git-demo-project

Now, tell Git to start tracking this folder by initializing a new repository:

git init

You won't see anything obvious happen, but Git just created a hidden .git folder inside git-demo-project. This folder is the brain of your repository.

The Three Stages of Git

To save a file in Git, it goes through three stages:

  1. Working Directory: You create or edit a file.
  2. Staging Area: You tell Git, "I want these specific files to be included in the next snapshot."
  3. Committed: You permanently save the snapshot to the history log.

Create a simple HTML file using the terminal:

touch index.html

Open index.html in VS Code, add a simple <h1>Hello Git!</h1>, and save the file.

Check the status of your repository by typing:

git status

You will see index.html listed in red as an "Untracked file". Git sees the file, but isn't watching it for changes yet. Let's move it to the Staging Area:

git add index.html

Run git status again. The file is now green, meaning it is staged and ready to be committed. Now, let's take the snapshot:

git commit -m "Initial commit: Added index.html"

The -m flag stands for "message". Every commit needs a descriptive message so your team knows what changed.

To view your project's history, type:

git log

You will see your commit hash, your name, the date, and your message.

Pushing to the Cloud

Right now, your repository only exists on your local machine. If your hard drive fails, your code is gone. We need to push it to a remote server.

  1. Go to https://github.com and log in.
  2. Click the + icon in the top right corner and select New repository.
  3. Name the repository git-demo-project.
  4. Leave it as Public and do not check "Initialize this repository with a README" (since we already have local files we want to upload).
  5. Click Create repository.

GitHub will show you a page of setup instructions. Look for the block titled "...or push an existing repository from the command line". Copy the first two commands and paste them into your VS Code terminal. They will look similar to this:

git remote add origin [https://github.com/your-username/git-demo-project.git](https://github.com/your-username/git-demo-project.git)
git branch -M main
git push -u origin main

Refresh your GitHub page in the browser. You will now see your index.html file live on the internet!

Visualizing the Workflow

While typing commands in the terminal makes you look like a hacker, visual tools are often much better for understanding complex file changes. VS Code has a fantastic Git GUI built right in.

Create a new file in your project called style.css and add some basic CSS:

body {
    background-color: #f4f4f4;
    font-family: Arial, sans-serif;
}

Save the file, then open index.html and link the CSS file inside the <head>. Save that file too.

Instead of going to the terminal, look at the Activity Bar on the far left of VS Code. Click the Source Control icon (it looks like a branch with three nodes, and it should currently have a blue badge with a ‘2' on it).

  1. The Diff: Click on index.html in the Source Control panel. VS Code will open a split-screen view. The left side shows the old version, and the right side shows your new version, with the changes highlighted in green. This is incredibly useful for reviewing code before committing.
  2. Staging (git add): Hover over the word Changes in the Source Control panel and click the + icon. This moves all modified files into the Staged Changes section. (This is the visual equivalent of git add .).
  3. Committing (git commit): In the Message text box at the top of the panel, type "Added basic styling and linked CSS". Click the Commit button.
  4. Pushing (git push): Click the Sync Changes button that appears, or click the three dots (...) at the top of the panel and select Push.

You have just executed the entire Git workflow without typing a single terminal command.

Creating a Feature Branch

Imagine you have a working Web Architecture assignment, but you want to try adding a risky new spatial computing visualization. If you edit your main files and it breaks, your assignment is ruined. Branches solve this.

Let's create a branch using the terminal:

git switch -c experimental-feature

The -c flag creates a new branch and immediately switches you to it.

Open index.html, change the <h1> text to <h1>Hello Experimental Git!</h1>, and save it.

Use the VS Code Source Control panel to Stage and Commit this change with the message "Testing branch workflow".

Switching Branches

Now, let's look at the magic of Git. Open index.html in your editor so you can see the text.

In your terminal, type:

git switch main

Watch the code in VS Code. The text instantly reverts to <h1>Hello Git!</h1>. Your experimental code is safely stored on the other branch.

To bring that feature into your main code, ensure you are on the main branch, and run:

git merge experimental-feature

Your main branch has now absorbed the changes from the feature branch.

Well Done

You have successfully navigated the steepest part of the developer learning curve. Version control can feel abstract and frustrating at first, but it is the bedrock of modern software engineering. Whether you are using the terminal to script automated deployments, or relying on VS Code's visual diffs to catch a missing semicolon, you now have the tools to track, save, and share your code safely.

Moving forward, every piece of coursework or lab project you write should start with git init. Commit early, commit often, and never name a file final_v3 again.