Why the Source Repository Matters

A deployed website is the output.

Your repository is the history of the source that produced it.

Those are not the same artifact.

Two evidence systems

A published page can tell someone:

This is what the site looks like now.

A Git repository can tell someone:

• what source changed;
• when it changed;
• why a commit says it changed;
• which version introduced a bug;
• which files belong to the project;
• what another developer could clone and rebuild.

For a technical portfolio, that history matters.

Git is not GitHub

Git is the version-control system operating on your repository/history.

GitHub is a hosting/collaboration service that can host Git repositories and connect them to features such as pull requests, Actions, and Pages.

You can use Git without GitHub.

You can also upload files to GitHub without understanding Git very well.

This Unit makes the boundary explicit.

The project source of truth

Your repository should contain the source needed to build the site:

_config.yml
Gemfile
Gemfile.lock
_layouts/
_includes/
_data/
_posts/
_projects/
assets/
page source

Generated _site normally does not need to become the authoring source simply because it is deployable output. Your exact deployment workflow determines what artifacts are stored where.

Public-repository boundary

Before publishing a repository, search for:

• passwords;
• tokens;
• private keys;
• API credentials;
• private school/student records;
• local machine secrets;
• accidental .env files;
• private screenshots/data.

Git history can preserve old committed secrets even after the current file is deleted.

Do not commit a secret and assume a later deletion erases the exposure.

Portfolio action

Create a source-inventory list:

Must be versioned:
Should be ignored/generated:
Must never be committed:

Defend every category.

Checkpoint

Explain why a live portfolio URL is not enough evidence for a technical project without the source/history that produced it.