First repository

Create the repository

> mkdir my-first-repo      # a fresh folder for today's practice
> cd my-first-repo
> git init
Initialized empty Git repository in .../my-first-repo/.git/

git init creates the hidden .git folder, the local repository from the four-areas map. Your folder looks unchanged in the file explorer; the history machinery lives inside .git, and you never edit that folder by hand. Ask Git what it sees:

> git status
On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

git status is the command you will type more than any other. It never changes anything; it reports where every file stands and, helpfully, prints the command for whatever you probably want next. When in doubt, status.

Write the README, in Markdown

Every serious repository has a README.md: the front page GitHub renders when someone opens the project. It is written in Markdown, plain text with a few conventions for structure, and it is the format of the Assignment 1 document and your project documentation. Create the file in any editor (Notepad, VS Code) inside my-first-repo, with content like:

# My first repository

Practice repository for 420-302-VA, Week 1.

## What I learned today

- Creating a repository with `git init`
- The edit, status, add, commit cycle

## A command worth remembering

```
git status
```

The conventions on display: # and ## make headings, - starts a list item, backticks mark code (single for inline, triple for a block). That is most of what Assignment 1 needs; the full vocabulary is one page: Markdown basic syntax, and GitHub's own writing and formatting guide.

The daily cycle

Run the loop on your README:

> git status
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md
> git add README.md          # stage this file ("git add ." stages everything changed)
> git status
Changes to be committed:
        new file:   README.md
> git commit -m "Create README with Week 1 notes"
[main (root-commit) 3f1e9a2] Create README with Week 1 notes
 1 file changed, 12 insertions(+)

Now change something, add a line to the "What I learned" list, save, and run the loop again with a message like "Add commit cycle to learned list". Do it a third time. Three commits is a history worth reading.

Read your history

> git log --oneline
b92ee54 (HEAD -> main) Add commit cycle to learned list
8c47d01 Add install steps
3f1e9a2 Create README with Week 1 notes
> git diff                   # what changed in the working directory since the last commit
> git diff --staged          # what is staged, i.e. what the next commit would contain

git log --oneline shows one commit per line, newest first, with the short identifier from the history-chain diagram; HEAD -> main marks where you stand. git diff answers "what did I actually change?" line by line, additions and removals marked, which is worth reading once before every commit: it catches the debug line you forgot to remove.

The safety net: undo without fear

The promise from the start page, that almost nothing committed is ever lost, comes with practical commands. The two worth knowing in week one both operate before history is touched:

> git restore README.md            # discard uncommitted edits: back to the last commit's version
> git restore --staged README.md   # unstage: take it off the loading dock, keep the edits

• Ruined a file while experimenting? git restore <file> throws away the uncommitted changes and returns the file to its last committed state. This is the one command here that discards work, so read its name twice before Enter.
• Staged the wrong file? git restore --staged <file> only un-picks it from the next commit; your edits stay in the working directory.
• Committed something embarrassing? The history-editing tools (revert, reset, commit --amend) exist and are one week too early; for now, simply make a new commit that fixes it. Forward fixes are always safe.

Telling Git to ignore files

Some files should never enter history: editor backups, generated files, and later this semester Python's __pycache__ folders and virtual environments. A file named .gitignore at the repository root lists patterns to leave untracked:

__pycache__/
*.pyc
.venv/
.DS_Store

Commit the .gitignore itself; it is part of the project. You will meet the Python entries for real in Week 4; today it is enough to know the mechanism exists, and that the fix for "why is this junk file in git status" is one line in this file.

Checklist for this stage

• my-first-repo exists and git status answers inside it
• README.md written in Markdown: a heading, a list, a code block
• At least three commits, made one loop at a time, with messages that say what changed
• git log --oneline shows my history and my authorship (spot-check with git log)
• I tried git diff before a commit and git restore on a scratch change

Check yourself