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.