Skip to main content

Git Without GitHub

In this guide, you’ll use Git locally only. No GitHub yet.

In this tutorial you will:

  • Create a folder for a project
  • Turn it into a Git repository
  • Make your first commits
  • Practice the day‑to‑day Git workflow that you’ll use constantly

1. Create your first local repository​

Pick a place where you keep code projects, for example ~/code.

If you're not familiar with these commands, see the files and directories guide.

# create your project folder
mkdir -p ~/code/my-first-git-project

# navigate into your project folder
cd ~/code/my-first-git-project

Now turn this folder into a Git repository:

git init

Git creates a hidden .git directory.
That folder is where Git stores all history and metadata.

You now have:

  • A working directory: my-first-git-project/
  • An empty repository with no commits yet

Check the status:

git status

You should see something like:

On branch main

No commits yet

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

2. Create a file and see what Git notices​

Create a simple file:

echo "Hello Git!" > notes.txt

Learn more about viewing and editing files in the command line.

Check status again:

git status

Now you’ll see:

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    notes.txt

Tracked vs untracked​

  • Untracked: Git sees the file exists, but is not tracking it yet
  • Tracked: Git is watching the file for changes and can include it in commits

New files start as untracked until you explicitly add them.

3. Stage and commit your first change​

Step 1: Stage the file​

Add notes.txt to the staging area:

git add notes.txt

Check status:

git status

You should see:

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    new file:   notes.txt

This means:

  • The working directory and staging area now include notes.txt
  • The repository still has no commits

Step 2: Create your first commit​

git commit -m "Add initial notes file"

Git opens a new entry in the project’s history with:

  • The content of the staged changes
  • Your name and email (from git config)
  • The commit message

Check the log:

git log --oneline

You should see one commit, something like:

abc1234 Add initial notes file

You’ve just:

  • Edited the working directory
  • Staged changes into the staging area
  • Saved a snapshot into the repository

4. The everyday Git loop​

Most of your time with Git follows this simple cycle:

  1. Edit files in your editor
  2. See what changed
  3. Stage the changes you want to keep
  4. Commit those staged changes with a clear message

Let’s walk through this with your notes.txt file.

Step 1: Edit a file​

Open notes.txt in your editor and make a few changes, e.g.:

Hello Git!

- Learn how commits work
- Practice staging changes
- Push to GitHub later

Step 2: Check what changed​

git status

You’ll see:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
    modified:   notes.txt

To see the actual line‑by‑line changes:

git diff

Step 3: Stage the changes​

You can stage everything:

git add .

Or just a specific file:

git add notes.txt

Check status:

git status

You should now see changes to be committed.

Step 4: Commit with a meaningful message​

git commit -m "Expand notes with learning checklist"

Run:

git log --oneline

Now you have two commits forming a simple history.

5. Writing good commit messages​

Commit messages are tiny pieces of documentation. Good messages make history readable.

Some tips:

  • Use the present tense (“Add feature” not “Added feature”)
  • Explain why the change exists, not just what files changed
  • Keep it short but specific:
    • Fix login bug when username is blank
    • Refactor user service to separate validation

Avoid:

  • misc changes
  • fix
  • wip (work‑in‑progress) as a final commit message

6. Summary: Git without GitHub​

You’ve learned the 90% workflow you’ll use every day:

edit files → git status → git diff → git add → git commit

At this point:

  • Your project is version‑controlled locally
  • You can see its history with git log
  • You can safely experiment, knowing you can always go back to an earlier commit

Next, you’ll learn what GitHub adds on top—remotes, backups, and collaboration—and then connect this local repository to GitHub.