Git & Command Line · Lesson 2 of 5

Git Basics

Repositories, commits, staging and reading history.

• Beginner
• 15 min read
• 3 objectives

Before this lessonLesson 1: Command Line Essentials

Git is a version control system: it records the history of your project so you can see what changed, when and why, go back to any earlier state, and work with others without overwriting each other. Almost every software team uses it.

The problem Git solves

You have probably saved files called report_final.docx, report_final2.docx and report_REALLY_final.docx. Now imagine ten people editing the same project. Git is a system that remembers every version of every file, who changed what and why, and lets you go back to any point. Instead of copies of files, you keep one folder plus a complete history.

Git is also what makes teamwork possible. Everyone works on their own copy, and Git combines the changes. It is the industry standard, used by essentially every software team and hosted by services such as GitHub and GitLab.

Setup

git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

The three areas

• Working directory: your files as they are right now.
• Staging area (index): the changes you have chosen to include in the next commit.
• Repository: the permanent history of commits.

The staging area is what lets you craft a clean commit from a messy day of edits: stage only the related changes together.

Your first repository

mkdir my-project && cd my-project
git init
echo "# My Project" > README.md

git status                    # what is going on?
git add README.md             # stage it
git commit -m "Add README"    # record it

[main (root-commit) a1b2c3d] Add README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

The everyday loop

# edit files...
git status               # see changed files
git diff                 # see what changed (unstaged)
git add -p               # stage chosen hunks interactively
git add .                # or stage everything
git diff --staged        # review what will be committed
git commit -m "Fix login redirect"

Reading history

git log                        # full history
git log --oneline --graph -10   # compact view
git show a1b2c3d                # one commit's changes
git blame README.md             # who last changed each line

Good commits

• One logical change per commit. It should be easy to describe in one line.
• Write in the imperative: "Add search filter", not "added" or "stuff".
• Keep the first line under about 50 characters; add detail after a blank line if needed.

.gitignore

List files Git should never track: dependencies, build output, secrets.

node_modules/
.venv/
__pycache__/
.env
.DS_Store
dist/

Think of commits as save points in a game

A commit is a snapshot of your project at one moment, with a message explaining it. You can always return to an earlier save point. A history is simply a chain of these snapshots, each pointing at the one before it.

commit 3  "Add contact form"      <- you are here
   |
commit 2  "Style the header"
   |
commit 1  "Create homepage"

A complete first walkthrough

Follow along in an empty folder. Each command is explained so nothing is magic.

$ mkdir my-site && cd my-site
$ git init                       # start tracking this folder
Initialized empty Git repository in .../my-site/.git/

$ echo "<h1>Hello</h1>" > index.html
$ git status                     # what has changed?
Untracked files:
        index.html

$ git add index.html             # stage: choose what goes in the next snapshot
$ git commit -m "Create homepage" # commit: take the snapshot
[main (root-commit) 3f2a91c] Create homepage
 1 file changed, 1 insertion(+)

$ git log --oneline              # view the history
3f2a91c Create homepage

Why is there a staging area?

You may have edited five files but only want two of them in this commit because they belong to one idea. git add lets you pick exactly what goes into the snapshot. It feels like an extra step at first; later it is what keeps your history clean and understandable.

The three states of a file

• Modified: you changed it, but Git has not been told to include it yet.
• Staged: you ran git add; it will be in the next commit.
• Committed: it is safely stored in the history.

git status tells you which state each file is in. When you are lost, run it. It is the most useful Git command and also suggests what to do next.

Seeing what changed

$ echo "<p>Welcome</p>" >> index.html
$ git diff                       # changes not yet staged
+<p>Welcome</p>

$ git add index.html
$ git diff --staged              # changes that will be committed

Key takeaways

• Git keeps a complete history of your project as a chain of commits (snapshots).
• The everyday loop: edit, git add, git commit -m.
• git status, git diff and git log --oneline tell you where you are.
• Write commit messages that explain why; your future self will thank you.

# Write your solution here