Put your source in a private GitHub repository

1. Understand a commit

Git stores snapshots called commits. GitHub hosts a copy of that history. A commit on your computer is not yet a push; a push is not yet a successful website deployment.

Run these commands in my-blog if it is not already a Git repository:

git init -b main
git config user.name "Your Name"
git config user.email "YOUR_GITHUB_COMMIT_EMAIL"
git status --short

Replace the email placeholder with your chosen commit email. GitHub provides a no-reply address in account email settings if you prefer not to put your personal address in commit metadata. These commands configure this repository rather than every repository on the computer.

Review .gitignore from Lesson 03. Do not commit installed dependencies, generated output, credentials, environment files, or database backups. Ignoring a file does not remove it if it was already tracked.

git add .
git diff --cached --stat
git diff --cached

Read the staged changes before committing. Your Markdown drafts are allowed in the private repository, but credentials are not. Then:

git commit -m "Build the initial Markdown blog"

If your machine already uses signed Git commits, retain that setup. With 1Password signing, approve the local request and retry the intended commit if it fails. A chat message cannot unlock the password manager or approve the key. Signing is optional for a new student’s repository; do not switch off an existing signing policy just to finish a lesson.

2. Create an empty private repository

Sign into GitHub. Choose New repository, name it my-blog, and select Private. Leave README, license, and .gitignore initialization unchecked because those choices would create a separate initial history. GitHub’s new repository guide describes the current screen.

Do not add collaborators for this course. Confirm the repository page displays the Private badge.

Copy its HTTPS URL and connect it locally:

git remote add origin https://github.com/YOUR_USERNAME/my-blog.git
git remote -v
git push -u origin main

Use GitHub’s supported credential manager/browser authorization for HTTPS, or your already configured SSH access. GitHub account passwords are not Git HTTPS credentials. Never paste a token into a remote URL or into chat.

If the remote was already configured, inspect git remote -v first and use the intended repository; do not overwrite a different project’s remote. If you accidentally initialized the remote with files, resolve the histories deliberately instead of force-pushing over unknown content.

3. Verify the remote copy

git status
git rev-parse HEAD
git rev-parse origin/main

The two hashes should match after the push, and the worktree should be clean. On GitHub, open src/content/blog/hello-world.md and check that it is the expected file. Confirm visibility is Private one more time.

The repository’s private source can still produce a public site on Cloudflare. We are not enabling GitHub Pages. Cloudflare will receive authorized access to this repository in Lesson 10.

Common fixes

• “Remote origin already exists”: inspect the existing remote and confirm the target.
• “Authentication failed”: reauthenticate using GitHub’s supported flow; verify which account is selected.
• “Host key verification failed”: if using SSH, verify GitHub’s host key using its official documentation. Do not disable host-key checks.
• “Failed to write commit object” with 1Password: complete the local signing approval and retry; a push cannot upload a commit that was never created.

Checkpoint

The source exists in your own private GitHub repository, the commit appears remotely, and your local branch matches origin/main. You can explain the difference between editing, committing, pushing, and deploying.