Lesson 5 - Guided Project: Version-Control SkyLog

Welcome to the Guided Project#

It’s time to put the whole module to work. In this guided project you’ll build SkyLog — a tiny command-line journal for recording what you see in the night sky — and place it under version control from its very first file. You’ll run git init, stage and commit your work in small logical steps, and end with a clean three-commit history you can read at a glance. SkyLog isn’t a throwaway exercise, either: it’s the running example for the rest of this course, so the repository you create here is one you’ll keep growing as you learn branching, history, and GitHub.

By the end of this project, you will be able to:

• Create a new project folder and turn it into a Git repository with git init
• Stage changes with git add and record them as commits with git commit
• Build a history of several focused commits, each with a clear message
• Inspect your work with git status and git log

Work along in your own terminal — type the commands rather than reading past them. Let’s build SkyLog.

Stage 1: Create the Project and Initialize Git#

Start by making a folder for the project and moving into it. Then turn that ordinary folder into a Git repository with git init.

$ mkdir skylog
$ cd skylog
$ git init
Initialized empty Git repository in /home/you/skylog/.git/

The path in your output will reflect wherever you created the folder, but the message will be the same. Git has added a hidden .git subdirectory — that’s where all of your project’s history will live. The repository is empty for now, which git status confirms:

$ git status
On branch main
No commits yet
nothing to commit (create/modify files to add and track)

A repository with no commits is a blank slate. Let’s give it something to track.

Stage 2: First Commit — the README#

Every project deserves a README explaining what it is. Create a file called README.md with this content:

# SkyLog

A tiny command-line journal for logging what you see in the night sky.

Now stage just that file and make your first commit:

$ git add README.md
$ git commit -m "Add project README"
[main (root-commit) 57d9883] Add project README
 1 file changed, 3 insertions(+)
 create mode 100644 README.md

A few things to notice in that output. (root-commit) appears only on the very first commit in a repository — the one with no parent. 57d9883 is the short form of this commit’s unique hash; yours will be different, and that’s completely expected. Git also tells you it recorded one new file with three inserted lines. The slate is no longer blank.

Stage 3: Commit the Script#

Now add the actual tool. Create a file called skylog.py with this content:

import sys

def add(observation):
    with open("observations.md", "a") as f:
        f.write(f"- {observation}\n")
    print(f"Logged: {observation}")

if __name__ == "__main__":
    add(" ".join(sys.argv[1:]))

This small script appends whatever you type to a file named observations.md and prints a confirmation. While you’re here, add a short usage line to the bottom of README.md so people know how to run it:

Usage: `python skylog.py "what you saw"`

You’ve now changed two files — a new script and an edited README. This time, stage everything at once with git add . and commit:

$ git add .
$ git commit -m "Add SkyLog script and usage notes"
[main bb57806] Add SkyLog script and usage notes
 2 files changed, 11 insertions(+)
 create mode 100644 skylog.py

Notice there’s no (root-commit) label this time — this commit builds on the previous one. Git reports two files changed and a new skylog.py created. Your project now has a tool, not just a description of one.

Stage 4: Run the Tool, Then Commit Its Output#

Let’s actually use SkyLog. Run it a couple of times to log some observations:

$ python skylog.py "Orion Nebula, naked eye, 9:40pm"
Logged: Orion Nebula, naked eye, 9:40pm
$ python skylog.py "Jupiter and four moons through binoculars"
Logged: Jupiter and four moons through binoculars

Each run appended a line to observations.md. Take a look at what the tool produced:

$ cat observations.md
- Orion Nebula, naked eye, 9:40pm
- Jupiter and four moons through binoculars

That file is brand new and untracked, so let’s record it as its own commit — the journal’s first entries deserve their own checkpoint:

$ git add observations.md
$ git commit -m "Log first two observations"
[main 573e746] Log first two observations
 1 file changed, 2 insertions(+)
 create mode 100644 observations.md

That’s three commits: the README, the script, and the first observations. Each one is a small, self-contained step.

Stage 5: Review the History#

You’ve built something — now read it back. The quickest overview is git log --oneline, which prints one line per commit:

$ git log --oneline
573e746 Log first two observations
bb57806 Add SkyLog script and usage notes
57d9883 Add project README

Newest first, oldest last. Those three short hashes match the three commits you made, and the messages read like a story of how the project came to be. For the full detail of the most recent commit, use git log -1:

$ git log -1
commit 573e7466305c95ee9d40541ab4a80392c4588464
Author: Ada Skye <[email protected]>
Date:   Sun Jun 28 14:32:56 2026 +0330

    Log first two observations

Here you see the full 40-character hash, the author and email (these come from the git config identity you set in Lesson 2, so yours will show your name and email), the timestamp, and the full message. Finally, confirm the working tree is clean — that everything you’ve created has been committed and nothing is left dangling:

$ git status
On branch main
nothing to commit, working tree clean

“Nothing to commit, working tree clean” is the phrase you want to see at the end of a work session. It means your saved history matches your files exactly. SkyLog is now a real, version-controlled project.

Extend the Project#

The project is healthy and clean — a perfect base to practice on. Try these on your own, committing each as its own step.

Exercise 1: Add a license and commit it#

Create a LICENSE file (a one-line note like MIT License - free to use and modify is fine for practice), then stage and commit it on its own.

Exercise 2: Make a small edit and commit it clearly#

Improve the README — add a line describing what the observations.md file is, for example. Then commit the change with a message that says what you changed and why.

Exercise 3: See what each commit changed#

Run git log --stat to view your history with a per-commit summary of which files changed and by how many lines.

Summary#

In this project you built SkyLog, a small command-line stargazing journal, and put it under version control from its first file. You ran git init to create the repository, then built a clean three-commit history: you committed the README, committed the script, and ran the tool to generate observations.md before committing that too. Along the way you staged work with git add (both a single file and everything at once with git add .), recorded it with descriptive git commit -m messages, and reviewed the result with git log --oneline, git log -1, and a final git status showing a clean working tree. This is the complete everyday Git loop — and SkyLog is now the repository you’ll carry forward through the rest of the course.

Key Concepts#

• git init — turns an ordinary folder into a Git repository.
• git add — stages changes (one file, or everything with git add .) for the next commit.
• git commit -m — records the staged changes as a snapshot with a message.
• Small, logical commits — each commit is a focused checkpoint you can read and return to.
• git log / git status — read your history and confirm the working tree is clean.

Why This Matters#

Knowing the commands individually is one thing; running them together to take a project from empty folder to clean history is the skill that actually matters. That full loop — init, edit, stage, commit, review — is what you’ll repeat thousands of times across your career, on every project you touch. Building SkyLog with a tidy, intentional history also sets up everything ahead: in the next module you’ll read, compare, and undo exactly the kind of commits you just made.

Next Steps#

Continue Building Your Skills#

You’ve completed Module 1: you understand what version control is, you have Git installed and configured, you know how to create a repository, stage, and commit — and you’ve proven it by building SkyLog with a clean three-commit history. Keep this repository; you’ll grow it as the course continues. Next, you’ll learn to work with that history — reading it in detail, comparing versions, and undoing changes when you need to.