Lesson 5 - Guided Project: Publish SkyLog to GitHub

Welcome to the Guided Project#

Across this module you learned each piece on its own: what GitHub is, how to register a remote, how to push, and how to keep local and remote in sync. Now you’ll put it all together in one continuous run. Starting from your local SkyLog repository — the small project you’ve been building, with its commits and README already in place — you’ll take it from “lives only on my laptop” to “online, backed up, and shareable” in a single sitting.

This is the moment the work becomes real. By the time you finish, anyone with the link can view SkyLog’s files and read its README on GitHub, and every future commit will be one short command away from being published.

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

• Create an empty repository on GitHub using the web interface or the gh CLI
• Connect your local repo to that remote and publish it with a first push
• Confirm your files and README render correctly on the GitHub repo page
• Push a follow-up change with a plain git push and prove the project is truly online

Work through the stages in order, running each command in your own SkyLog repo as you go. Your account name, commit hashes, and object counts will differ from the ones shown here — that’s expected. Let’s publish.

Stage 1: Create the Empty Repository on GitHub#

A push needs somewhere to push to, so the first step is to create an empty repository on GitHub. Pick whichever of these two paths you prefer.

Option A — the web interface. Sign in at github.com, click the green New button, and fill in the form:

• Repository name: skylog
• Description (optional): a one-line summary such as “A small flight-logging project.”
• Visibility: Public (so you can share the link) or Private (only you and people you invite).
• Initialize this repository with a README: leave this unchecked.

Then click Create repository. You’ll land on a page that shows setup instructions — that’s the empty repo waiting for your first push.

Option B — the gh CLI. If you have the GitHub CLI installed and signed in, you can create the repo from the terminal:

gh repo create skylog --public --source=. --remote=origin

That creates an empty skylog repo on GitHub and registers it locally as origin, all in one command — no web form needed. (You’ll see a one-command variant that also pushes at the end of this project.)

Whichever route you took, you now have an empty repository on GitHub. Note its URL — in this project it’s [email protected]:datatweets/skylog.git (the SSH form). Yours will use your own account name in place of datatweets.

Stage 2: Connect the Local Repo to the Remote#

Skip this stage if you used gh repo create in Stage 1 — it already wired up origin. You can jump to Stage 3 (or run git remote -v to confirm).

If you created the repo through the web interface, your local SkyLog repo doesn’t yet know where the remote lives. Register it with git remote add, giving it the conventional name origin and the URL from Stage 1:

$ git remote add origin [email protected]:datatweets/skylog.git

That command prints nothing, which is normal — it simply records a name-and-URL pairing; no files move yet. Confirm it landed with git remote -v:

$ git remote -v
origin  [email protected]:datatweets/skylog.git (fetch)
origin  [email protected]:datatweets/skylog.git (push)

The one remote shows up twice: Git tracks the URL it would fetch from and the URL it would push to separately. For SkyLog they’re identical, as they almost always are. Your local repo now knows exactly where its hosted copy lives.

Stage 3: Publish with Your First Push#

With the remote connected, you can send your commits up. The first push names the remote and the branch, and adds the -u flag:

$ git push -u origin main
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Over a real network connection, Git prints transfer progress before those two lines — messages like Enumerating objects, Counting objects, and Writing objects as it packs up and uploads your commits. The exact numbers depend on how much history SkyLog has, so don’t be thrown by that scroll of activity. The two lines that matter are the ones above:

• * [new branch] main -> main confirms your local main was published as a new branch on the remote.
• branch 'main' set up to track 'origin/main'. is the result of -u (short for --set-upstream): it permanently links your local main to the remote’s main, so every later push is just git push.

SkyLog is now on GitHub.

Stage 4: Confirm It Online#

Don’t just trust the terminal — go look. Open your repository in a browser at https://github.com/datatweets/skylog (using your own account name). The page should now show:

• The list of files you’ve been tracking, each with the message from its most recent commit.
• Your README rendered as formatted text below the file list — headings, lists, and links all displayed nicely. This is GitHub turning your plain README into a project home page.

Seeing your files and README on the repo page is proof the push worked. If the page still shows GitHub’s “set up” instructions instead, refresh — and if it’s empty, double-check Stage 3 ran without errors.

Stage 5: Make Another Change and Push Again#

A repo on GitHub is only useful if keeping it current is easy. Let’s prove that the second push and onward take no special flags. Make a small improvement locally — say, add a usage section to the README — then stage and commit it as usual:

$ git add README.md
$ git commit -m "Document usage"

Now publish it. Because Stage 3’s -u already set the upstream, you don’t name the remote or branch — a bare git push is enough:

$ git push
   bbe42af..3512e16  main -> main

That single line is Git’s way of saying it updated main on the remote, moving it from the old commit (bbe42af) to your new one (3512e16). Your hashes will be different — they’re computed from your content — but the shape is the same: old..new main -> main. Refresh the GitHub page and you’ll see the updated README and a new entry in the commit history. From here on, publishing any change is exactly this: commit, then git push.

Stage 6: (Optional) Clone It Elsewhere to Prove It’s Online#

To convince yourself SkyLog truly lives on GitHub and not just on your laptop, clone it into a different folder — somewhere outside your existing project. Cloning downloads a fresh, complete copy from the remote:

$ git clone [email protected]:datatweets/skylog.git
Cloning into 'skylog'...

Git creates a new skylog directory containing every file and the full commit history, already connected to origin. If you cd into it and run git log, you’ll see the same commits — including “Document usage” from Stage 5. That’s the backup-and-portability payoff in action: the repository can be reconstructed anywhere from the remote alone.

When you’re done experimenting, you can delete this cloned copy; your original SkyLog repo is untouched.

The one-command shortcut. Now that you’ve seen the steps spelled out, here’s how gh collapses Stages 1 through 3 into a single command. From inside your local repo, running:

$ gh repo create skylog --public --source=. --remote=origin --push

creates the GitHub repository, wires up origin, and pushes your commits — all at once. The --push flag is what adds the publish step on top of the create-and-connect you saw in Stage 1. It’s the fastest way to take an existing local project online, and it’s the same end result you reached the long way in this project.

Extend the Project#

Try these to deepen what you’ve published. Attempt each before opening the hint.

Exercise 1: Add a description and topics#

On your SkyLog repo page, add a short description and a few topics (tags like python or learning-project) so the project is easier to find and understand at a glance.

Exercise 2: Publish a new branch#

Create a local branch (for example git switch -c add-notes), make a commit on it, and push it to GitHub so the branch appears online alongside main.

Exercise 3: Add a LICENSE on GitHub and pull it down#

Use GitHub’s web interface to add a LICENSE file to the repo, then bring that new commit down to your local copy so the two stay in sync.

Summary#

You took SkyLog from a local-only project to a published GitHub repository in one end-to-end pass. You created an empty repo on GitHub (web New button or gh repo create, deliberately without a README), connected your local repo with git remote add origin <url> and verified it with git remote -v, then published everything with git push -u origin main — the -u setting the upstream so later pushes are effortless. You confirmed the result by seeing your files and rendered README on the GitHub page, made a follow-up commit, and shipped it with a plain git push. Finally you saw how cloning recreates the project anywhere, and how gh repo create ... --push performs create, connect, and push in a single command.

Key Concepts#

• Empty remote first — create the GitHub repo with no README so the first push is clean.
• git remote add origin <url> / git remote -v — connect to the remote and confirm the link.
• git push -u origin main — the first push, which also sets the origin/main upstream.
• Plain git push — all later pushes, once the upstream is set.
• git clone <url> — recreate a complete copy of the repo from the remote.
• gh repo create skylog --public --source=. --remote=origin --push — create, connect, and push in one command.

Why This Matters#

Publishing a project to GitHub is one of the most common things a developer does, and now you’ve done the whole loop without gaps: create, connect, push, verify, and update. The repository is a backup that survives a lost laptop, a portfolio link you can share with anyone, and the foundation for collaborating with others. Just as importantly, you’ve internalized the rhythm — commit locally, git push to publish — that every real project runs on. With SkyLog online, you’re ready for the part of Git that involves other people.

Next Steps#

Continue Building Your Skills#

SkyLog is now live on GitHub, complete with a rendered README and a follow-up commit pushed the easy way. You’ve connected the full path from local work to a shared online repository — the workflow behind nearly every project you’ll touch from here on. Next you’ll add the human dimension: forking repositories, proposing changes through pull requests, and reviewing code, so you can build software together with other people rather than alone.