Lesson 16 of 51 ~22 min
Course progress
0%

First Repo – From Init to First Push

Step-by-step guide to creating your first Git repository: from initialization, adding files, making commits, to pushing to a remote. Learn the solo and team workflows.

The first time you create a Git repository feels a little like moving into a new apartment. There’s nothing inside yet, just empty rooms and potential. In this chapter, we’ll walk through the lifecycle of creating your first repo: initializing, adding content, making commits, and finally pushing to a remote. It’s the “hello world” of Git, but with more bricks, paint, and moving boxes.

Initializing a Repository

To start, pick an empty directory and run:

mkdir my-first-repo
cd my-first-repo
git init

Git creates a hidden .git folder. This folder is the brain and heart of the repo—it holds all history, configs, and object data. Without it, your folder is just a directory of files.

Visualization:

flowchart TD
  WD[Working Directory] --> .git[.git Metadata]

This marks the difference between a normal folder and a Git repository.

Creating Your First File

Let’s add something:

echo "# My First Repo" > README.md

Check status:

git status

Git will show README.md as untracked. It’s in your working directory but not yet part of history.

Staging and Committing

To make Git remember it, stage and commit:

git add README.md
git commit -m "chore: add README.md"

Visualization of the cycle:

flowchart LR
  WD[Working Directory] -->|git add| Index[Staging Area]
  Index -->|git commit| Repo[Repository: Commit A]

Now the repo has history. The first snapshot lives forever.

Inspecting History

View history with:

git log --oneline

Output might show:

a1b2c3d chore: add README.md

That short hash is your commit ID, a unique fingerprint.

Adding More Files

Let’s expand:

echo "print('Hello, Git!')" > app.py
git add app.py
git commit -m "feat: add simple hello script"

Now you have two commits. Visualize with git log --graph:

gitGraph
  commit id: "README.md"
  commit id: "app.py"

Each commit extends the graph. You are building history.

Connecting to a Remote

Local repos are powerful, but collaboration requires remotes. Let’s say you created a repository on GitHub called my-first-repo. Connect it:

git remote add origin git@github.com:username/my-first-repo.git

Check remotes:

git remote -v

Visualization:

flowchart LR
  Local[Local Repo] -->|push/pull| Remote[GitHub Origin]

First Push

Push commits upstream:

git push -u origin main

The -u flag sets origin/main as the upstream for your main branch. From now on, you can just type git push.

Solo Workflow Example

As a solo developer, you create repos locally and back them up to GitHub or GitLab. This gives you redundancy and access from multiple machines.

git init my-tool
cd my-tool
echo "print('v1')" > tool.py
git add tool.py
git commit -m "init: first version"
git remote add origin git@github.com:me/my-tool.git
git push -u origin main

Team Workflow Example

On a team, one person creates the repo on GitHub. Everyone else clones it:

git clone git@github.com:org/project.git

Each developer makes branches, commits, and pushes. The central remote acts as a meeting point for all histories.

Visualization of team flow:

flowchart TD
  DevA[Dev A Local Repo] --> Origin[GitHub Origin]
  DevB[Dev B Local Repo] --> Origin
  Origin --> DevA
  Origin --> DevB

Think Different Mindset

Creating your first repo isn’t just about commands. It’s about declaring authorship. When you run git init, you say: this project has a history now. Every push is a broadcast of your narrative to others. Git transforms lonely code into communal story.

The journey from git init to git push is the foundation of every Git workflow. You’ve seen how to start, commit, and share. From here, we’ll dive into daily operations—adding, committing, checking diffs—so you can live comfortably in your repository instead of just visiting.