Viewing Code Changes Visually

Git can show code differences in the terminal, but command-line diffs are not always the easiest way for beginners to understand what changed. In real development work, many developers prefer visual tools such as VS Code or GitHub because they make added and removed lines much easier to see.

For this tutorial, we will mainly use VS Code because Git support is already built in, so you do not need to install a separate Git GUI just to inspect basic changes.

Viewing Changed Files in VS Code

When you open a Git repository in VS Code and modify a file, the Source Control view on the left side of the window will usually show that file.

For example, if you edit:

hello.txt

you may see a letter next to the file:

M

M means Modified.

A newly created file that Git is not tracking yet may appear with:

U

which usually means Untracked.

These indicators make it easy to see which files have changed without constantly switching back to the terminal.

Comparing Before and After

If you click a modified file in Source Control, VS Code usually opens a side-by-side comparison.

It may look something like this:

Before                         After

Hello Git                      Hello Git
                               Git is easy to learn.

One side shows the earlier version, while the other shows your current version. Added and removed lines are highlighted, making it easy to locate changes even in large files.

For example, if you change:

const name = "Alice";

to:

const name = "Bob";

the diff view will show the old line being removed and the new line being added.

This is much easier than rereading the entire file and trying to remember what changed.

Run git diff, remove the temporary console.log in the editor, then stage the clean change.

Why Check the Diff Before Committing?

Reviewing your diff before a commit is a very useful habit because it lets you confirm exactly what you are about to save.

Suppose you intended to change only:

login.js

but accidentally left some temporary debugging code in another file:

console.log("test");

If you do not review your changes, that debug line may end up in the commit. A quick look at the VS Code diff often catches mistakes like this before they become part of the project history.

A practical workflow is:

Edit code → review the diff in VS Code → confirm the changes → git add → git commit

Staged and Unstaged Changes

VS Code normally separates your changes into different sections. Files that have not been staged yet appear under Changes, while files that have already been added to the staging area appear under Staged Changes.

You can think of it like this:

Changes → not staged yet → Staged Changes → already staged → ready for the next commit

VS Code can also stage files for you. Clicking the + button next to a changed file is essentially the same as running:

git add <file>

Removing a file from Staged Changes does the opposite and returns it to the unstaged state.

There is no need to choose between the terminal and VS Code. A very common workflow is to use the terminal for commands such as git status and git commit, while using VS Code to review changes visually.

Viewing What Changed in an Existing Commit

Visual tools can also show changes from commits that have already been created. In VS Code or GitHub, you can open a commit and inspect which files changed and which lines were added or removed.

For example, if you see a commit called:

Fix login error

you can open it and inspect the exact changes made to login.js, rather than relying only on the commit message.

This is one of the reasons Git history is so useful. It preserves not only the latest version of the project, but also the individual changes that led to it.