Git Basics: Commit, Branch, Push

Every project changes over time. You fix a bug, try a new idea, rename a file, and a week later you cannot remember what the code looked like when it last worked. Git is a tool that records those changes for you, so you can look back at any earlier state, see exactly what changed and why, and try risky ideas without fear of breaking what already works. It is the standard way software teams keep track of their work, which makes it one of the first tools worth learning properly.

This chapter builds Git up from the ground. You will see how Git thinks about your files through its three areas, the working tree, the staging area and the repository, and how a commit turns a set of edits into a permanent snapshot. From there you will read your history with git status, git log and git diff, split work into branches so experiments never disturb your main line, and share everything with other people through a remote such as GitHub.

By the end you will be able to start or clone a repository, make clean commits with clear messages, move between branches, push and pull your work, keep unwanted files out with .gitignore, and undo a mistake without panic. The last pages collect the errors beginners hit most often and a cheat sheet you can keep beside you.

Every project changes over time. You fix a bug, rewrite a paragraph, try a risky idea, then wish you could undo it. Version control is a system that records every change to your files, along with who made it and when. Because each change is recorded, you can return to any earlier state of the project.

Think of it as an unlimited undo button that lasts for the whole life of the project, not just the current editing session. It also lets you ask questions such as what did this file look like last month? and who changed this line, and why?

Most people start by copying things by hand. You end up with a folder full of report_final.docx, report_final_v2.docx and report_final_v2_REAL.zip. It works for a day or two, then it falls apart: you cannot tell which copy is newest, what differs between two copies, or which one holds the fix you made last Tuesday.

Git is a distributed version control system. Older systems kept the history on one central server, and you needed a connection to it for almost everything. With Git, when you copy a project (a clone), you get the full history too, not just the latest files. Every clone is a complete repository.

In practice, committing, browsing history, comparing versions and creating branches all work on a plane with no Wi-Fi. You only need a network when you want to exchange changes with someone else, such as pushing to a hosting service.

Many people assume a version control tool stores a list of file-by-file differences. Git thinks differently. Each time you commit, Git records a snapshot of the whole project as it looks at that moment. Files that did not change are not copied again; Git just points to the identical stored content. Each snapshot also points back to the one before it, which forms the history.

Because every commit is a complete picture, going back to an old state means asking for that picture, with no need to replay a long chain of differences. Git can still show you the differences between two snapshots whenever you ask.

People often say Git and GitHub as if they were one thing. They are not. Git is the tool you run on your own computer. GitHub, GitLab and Bitbucket are hosting services built around Git: websites that store a copy of your repository online and add sharing and review features on top.

Before your first commit, confirm Git is installed by asking for its version. Any version number means it is ready; an error such as command not found means you must install it first.

git --version

Your exact version number will differ

Every commit is stamped with a name and an email address, so Git needs to know yours. You set them once with --global, which saves them for every repository on this computer. Use the same email you plan to use on your hosting service so your commits are linked to your account.

git config --global user.name "Asha Rao"
git config --global user.email "asha@example.com"
git config --global user.name

The last line reads the name back to confirm it was saved

Git does not watch every folder on your computer. A folder only becomes a Git project after you tell Git to start tracking it. The command that does this for a brand new project is git init.

Run git init inside a folder and Git creates a hidden folder named .git right there. That one folder is what turns an ordinary directory into a repository. Your existing files are not touched, and nothing is saved yet. Git has only prepared a place to keep history.

mkdir notes
cd notes
git init
ls -a

Start a new project from scratch

The ls -a flag shows hidden entries, so you can see .git sitting next to . and ... A normal ls hides it because the name starts with a dot.

Often the project already exists somewhere else, for example on GitHub. Instead of starting empty, you copy it with git clone <url>. Clone downloads the files and also the full history: every commit ever made, so you can browse the past offline.

Clone also records where the copy came from. It sets up a remote named origin that points at the URL you cloned from. Later, when you share work, origin is the name you will use to talk to that server.

git clone https://github.com/example/recipes.git
cd recipes
git remote -v

Copy a project and check the remote

By default Git names the new folder after the repository, here recipes. If you want a different folder name, add it after the URL.

git clone https://github.com/example/recipes.git my-recipes
cd my-recipes

Clone into a folder name you choose

The contents are identical. Only the local folder name changes, and origin still points at the same URL.

The two commands answer different situations. The question to ask is whether the project already exists somewhere.

Everything Git knows about your project lives in the .git folder: all the history and the repository settings, including the remote. Your visible files are just the current snapshot sitting beside it. This explains a surprising fact: if you delete .git, the repository is gone, history and all, but your files stay exactly as they were. They simply become an ordinary folder again.

Git does not simply save whatever is on your disk. It keeps your work in three separate places, and a change moves through them one step at a time. Once you know these places, most of Git's commands stop feeling mysterious.

The working tree is the folder of files you see and edit every day. When you open notes.txt in your editor and change a line, you are changing the working tree. Git notices the change, but it has not saved anything yet.

The staging area, also called the index, is a holding area. It lists exactly what the next commit will contain. Think of it as packing a box before you seal it: you choose what goes in, and only those items are shipped.

The repository is the hidden .git folder inside your project. It stores the full history of commits, and every commit is a permanent snapshot you can return to later. Delete .git and the project stays on disk, but the history is gone.

A change always moves in the same direction. You edit a file, you choose it with git add, and you save it with git commit. Each command is one step of the journey.

Here is the whole trip in a terminal. We create a file, stage it, then commit it. The git status --short command prints a two-letter code for each file, and A means the file is staged as a new addition.

$ echo "hello" > notes.txt
$ git add notes.txt
$ git status --short
A  notes.txt
$ git commit -m "Add notes file"
[main (root-commit) 3f2a1c9] Add notes file
 1 file changed, 1 insertion(+)
 create mode 100644 notes.txt
$ git status --short

After the commit, status prints nothing: all three places agree.

You might wonder why Git has a staging step at all. Why not commit everything at once? The reason is that real work is messy. In one afternoon you might fix a bug, tidy a comment and start a new feature. Staging lets you split those unrelated edits into separate, focused commits.

Suppose you edited app.py to fix a bug and README.md to correct a typo. You can stage and commit them one at a time, so the history tells a clear story, and each commit can be understood or undone on its own.

$ git add app.py
$ git commit -m "Fix crash when input is empty"
$ git add README.md
$ git commit -m "Correct typo in install steps"
$ git log --oneline
a81c4d2 Correct typo in install steps
5be90f7 Fix crash when input is empty

Two edits, two commits, each with one clear purpose.

At any moment, each file in your project is in one of four states. Git tracks which state a file is in, and git status shows it to you. When you are unsure what is going on, run git status first.

A file can loop around this cycle many times. Edit a committed file and it becomes modified, stage it and it is staged, commit it and it is committed again.

If you staged a file by accident, you can take it back out with git restore --staged <file>. The file moves from staging back to modified or untracked, but your edits stay exactly as they were. Nothing is lost.

$ git add app.py
$ git status --short
M  app.py
$ git restore --staged app.py
$ git status --short
 M app.py

The first column is staging, the second is the working tree. The edit is still there, only unstaged.

Editing a file does not save it into Git's history. A commit is a deliberate step in two moves: first you pick which changes belong together with git add, then you record them with git commit. The first move puts them in the staging area, a waiting room for the next snapshot.

The simplest form names the file you want. git add notes.txt stages that one file and leaves every other changed file alone. If you want everything that changed, git add . stages every change in the current folder and all folders below it. The dot means "here".

git add notes.txt
git add .
git status --short

Stage one file, then everything under the current folder

Sometimes one file holds two unrelated edits: a bug fix and a half-finished experiment. Committing both makes history hard to read and hard to undo. git add -p (the p is for patch) walks you through the file one hunk at a time. A hunk is a contiguous block of changed lines. For each hunk you answer a question: stage it or skip it.

git add -p app.py

Git shows each hunk and waits for your answer

After this session the price fix is staged and the debug print is not. The file is now in two states at once: the staged part will go into the next commit, and the rest stays as an ordinary edit in your working tree. You can confirm this with git status, which lists the same file under both "Changes to be committed" and "Changes not staged".

Once the right changes are staged, git commit -m "message" saves them. Git stores a snapshot of everything that is staged, together with your author name and email, the time, and the message you wrote. The -m flag lets you give the message right on the command line.

git commit -m "Fix item total to use quantity"

Saves the staged snapshot

The 3f9a1c2 in that output is the start of the commit's ID. Every commit gets a unique 40-character SHA-1 hash computed from its contents, its message, its author and time, and its parent. Git shows only the first seven characters by default, which is enough to tell commits apart in a small project.

Each commit also records which commit came right before it, called its parent. That link is what turns separate snapshots into a history: starting from the newest commit, Git can follow parent after parent back to the first one.

Because the hash depends on the parent as well, changing an old commit would change its hash and every hash after it. This is why history is treated as something you add to rather than edit.

If you run git commit without -m, Git opens your configured text editor with a template. Type the message on the first line, save and close the file, and the commit is made. Lines starting with # are comments and are ignored. If you close the editor with an empty message, Git cancels the commit. This is the comfortable way to write a message with a subject line and a longer explanation.

Git also refuses to commit when the staging area is empty. It will not create a snapshot with nothing new in it. The message tells you whether there is nothing changed at all, or whether you changed files but forgot to stage them.

git commit -m "Tweak app"

Edited app.py but never ran git add

The fix is to stage first, then commit. If instead the output says nothing to commit, working tree clean, there is simply nothing new to save.

Now suppose you committed and then spotted a typo in the message, or realised a file was missing. git commit --amend replaces the latest commit with a new one. Stage anything forgotten first, then amend. Adding --no-edit keeps the old message.

git add forgotten.py
git commit --amend --no-edit

Fold a forgotten file into the last commit

Notice the hash changed from 3f9a1c2 to 9d04e7b. Amend does not edit the old commit; it builds a new one and moves your branch onto it. That is harmless on your own machine, but it matters once the commit has been shared.

Every commit carries a message, and months from now that message is the only clue to why the change exists. Git does not care what you write, but your teammates and your future self will. A good message has a fixed shape: a short subject line, then a blank line, then an optional body.

The subject is written in the imperative mood, as if giving an order to the codebase: "Fix login redirect", not "Fixed login redirect" or "Fixes login redirect". A handy test is to complete the sentence "If applied, this commit will ...". Keep it to about 50 characters so it fits in one line of git log --oneline, and leave off the trailing period.

git commit -m "Fix login redirect"

A short subject is often all a small change needs

When the change needs explaining, leave a blank line after the subject and write a body. The body should answer why the change was made, because the diff already shows what changed. Without the blank line, Git tools treat the whole text as one long subject.

Running git commit with no -m opens your editor, which is the easiest way to write a multi-line message. Here is what one looks like:

Fix crash when cart is empty

Checkout read the first item without checking the list, so an
empty cart raised an IndexError. Return early and show the
"Your cart is empty" page instead.

Subject, blank line, then a body about the reason

A message is only useful if it says something specific. Messages like "stuff", "fix" or "changes" could describe any commit ever made, so they tell the reader nothing. Compare them with messages that name the problem or the feature.

Good messages are easier to write when each commit holds one logical change. If you fixed a bug and also renamed a variable and also tweaked a color, no single short message can describe all three honestly. You end up with a vague message such as "updates", or a long one joined with "and". Splitting the work into separate commits keeps every message short and true.

The staging area from earlier sections is what makes this possible. Use git add on just the files, or the parts of files, that belong together, commit them, then stage the next group.

git add cart.py
git commit -m "Fix crash when cart is empty"
git add theme.css
git commit -m "Darken the checkout button"

Two unrelated edits become two honest commits

Some teams add a short label to the front of the subject, following the Conventional Commits style. The prefix tells you the kind of change at a glance, so scanning a long history is much faster. Use it only if your team has agreed on it; otherwise plain imperative subjects are perfectly fine.

Small, focused commits pay off whenever you read the history. Each line of git log --oneline becomes a clear step in the story of the project:

They also make undoing safe. If the empty-cart fix turns out to be wrong, you can revert exactly that commit and nothing else. With a giant commit, reverting would throw away unrelated work along with the mistake.

git revert b2c3d4e

Creates a new commit that undoes only that one change

A quick routine before you commit keeps both mistakes away:

• Run git diff --staged and read every line you are about to record.
• Look for keys, passwords and debug prints that do not belong.
• Ask whether one short subject describes it all; if not, split the commit.
• Write the subject in the imperative, about 50 characters, with no period.

Git gives you three commands for looking at your work without changing anything. The first is git status. It answers one question: what is the state of my project right now? It compares the three areas you met earlier (working tree, staging area and repository) and reports the differences.

The report has four parts. It names the branch you are on, lists the staged changes that will go into the next commit, lists the unstaged changes (files Git tracks that you edited but did not stage), and lists untracked files that Git has never been told about.

git status

Run it from anywhere inside the repository

Read it from top to bottom. Here app.py is staged and ready, README.md was edited but not staged, and notes.txt is brand new to Git. If all three lists are empty, Git prints nothing to commit, working tree clean.

The long form is friendly but takes many lines. Once you know the layout, git status -s (short for --short) prints one line per file in two columns. The left column is the staging area compared with the last commit. The right column is the working tree compared with the staging area.

git status looks at the present. git log looks at the past. It lists the commits reachable from where you are, newest first. Each entry shows the full commit hash (the unique ID), the author, the date and the message.

The text in brackets after the first hash is a label. HEAD -> main means your checkout currently sits on the main branch at that commit. For a long history, git log opens in a pager: press q to leave it.

Full entries use a lot of space. Add --oneline to squeeze each commit onto one line with a short hash and the message. Add --graph to draw the branch shape with ASCII lines, and --all to include every branch rather than only the one you are on.

This picture shows two lines of work that split after 7c3e1fa. The * marks a commit, and the | and / characters show where lines run side by side and where they join. You will use this command constantly once branches enter the picture.

Status tells you which files changed, but not what changed inside them. git diff shows the lines themselves. Run on its own, it compares your working tree against the staging area, so it shows only changes you have not staged yet.

Lines starting with - were removed and lines starting with + were added. The @@ line tells you where in the file the change sits. The --- and +++ lines name the old and new versions.

Once you run git add, that change leaves the plain git diff output, because it is no longer unstaged. To review what is about to be committed, use git diff --staged (the older spelling --cached does the same). It compares the staging area against the last commit.

The third form takes two references. git diff main..feature shows what you would need to change on main to arrive at the feature branch. Hashes work too, so git diff 1b9d604..7c3e1fa compares two commits.

To inspect a single commit from history, use git show <hash>. It prints the commit header (author, date, message) followed by the diff that commit introduced. A short hash from --oneline is enough, as long as it is unique.

Each command answers a different question, and together they form a short check you should run before every commit. It takes seconds and catches the most common slips: a forgotten file, a stray debug line, or a change you did not mean to include.

First git status confirms that the files you expect are in the staged list and that nothing important is left untracked. Then git diff --staged lets you read the precise change. If you spot a leftover print or a password, fix it and stage again before committing, when it is cheap to correct.

Imagine you want to try a risky redesign of a login form while the rest of the project keeps working. Git's answer is the branch. A branch is a separate line of work, so you can experiment without disturbing the code your teammates, or your future self, rely on.

The surprising part is how cheap this is. A branch is not a copy of your files. It is a lightweight, movable pointer to one commit, stored as a tiny file holding a commit ID. Creating a branch writes one small pointer, so it is instant even in a huge project. When you commit, the branch you are on simply moves forward to the new commit.

Git also needs to know which branch you are working on right now. That is the job of HEAD, a special pointer to the branch (or, rarely, a specific commit) you currently have checked out. When you commit, Git adds the commit to whatever HEAD points at, and that branch moves forward. Other branches stay where they were.

Running git branch with no arguments lists your local branches and puts a star next to the one HEAD points at. Giving it a name, as in git branch name, creates a new branch at your current commit, but it does not move you onto it.

git branch
git branch login-form
git branch

List, create, list again

Look at the output: the star is still on main, so creating a branch did not change where you are. To move, use git switch name. Since you nearly always create a branch because you want to work on it, git switch -c name does both in one step: it creates the branch and moves HEAD onto it.

git switch login-form
echo "<form>" > login.html
git add login.html
git commit -m "Add login form markup"
git switch main
ls

Commit on the branch, then go back to main

Notice that login.html vanished when you returned to main. Git rewrote your working files to match the commit that main points to. Switch back and the file returns. Nothing was lost; the work is safe on the other branch.

When the feature is ready, you bring it back with a merge. The rule to remember is that git merge name combines the named branch into the branch you are on. So you first switch to the branch that should receive the work, usually main, and then merge.

What Git does next depends on the shape of the history. If main has not moved since you branched off, there is nothing to reconcile, and Git simply slides the main pointer forward to the feature's latest commit. This is a fast-forward merge. No new commit is created.

If both branches gained new commits, the histories have diverged, and a pointer move cannot combine them. Git instead builds a merge commit, a special commit with two parents that joins both lines. Git opens your editor with a default message, which you can normally accept.

To see the shape for yourself, git log --oneline --graph draws the branches with ASCII lines.

Git merges most changes automatically, because edits in different files or different parts of a file do not collide. A merge conflict happens only when both branches changed the same lines. Git cannot guess which version you want, so it stops, leaves the merge half done and asks you to decide.

Open the named file and you will find both versions wrapped in markers. Everything between <<<<<<< and ======= is your current branch's version, and everything between ======= and >>>>>>> comes from the branch you are merging in.

<<<<<<< HEAD
Welcome back!
=======
Hello again, friend
>>>>>>> login-form

The conflicted region in title.txt

Resolving means editing the file into the text you actually want, and deleting all three marker lines. The result might keep one side, the other, or a blend of both. Then you tell Git the conflict is settled by staging the file and committing.

Once a branch has been merged, its pointer has done its job and the commits stay in history. Delete it with git branch -d name. The lowercase -d is the safe option: Git refuses if the branch holds commits that are not merged anywhere, so you cannot lose work by accident.

If it already happened, the fix is easy because branches are cheap. Create a branch at the current commit, then move main back one commit. The work now lives safely on the new branch. Only do the second command while the commit exists on that new branch, since reset --hard discards changes.

git branch fix-login
git reset --hard HEAD~1
git switch fix-login

Rescue a commit made on main by mistake

The message gives you the two ways out. Either commit your changes first, or park them with git stash, switch, and later bring them back with git stash pop. Doing neither and forcing the switch would throw the edits away, so avoid that.

So far everything has lived on your own machine. A remote is a named copy of your repository hosted somewhere else, such as GitHub. Remotes give you a backup, a way to share work with teammates, and a place to review changes. By convention the first remote is called origin, but that is only a default name, not something special.

If you started with git clone, origin is already set up for you. If you started with git init, you connect your local repository to an empty repository you created on GitHub using git remote add. You can then list what is configured with git remote -v, which shows each remote's name and URL for fetching and pushing.

git remote add origin https://github.com/you/notes.git
git remote -v

Connect the local repo to GitHub, then check the connection

Adding a remote only records a name and a URL. Nothing is uploaded yet. To upload your commits you use git push. The first time, add -u so Git remembers which remote branch your local branch tracks. That link is called the upstream.

git push -u origin main

Upload main and set its upstream

After that one command, a plain git push or git pull on this branch knows where to go, so you no longer have to type the remote and branch names.

Teammates push too, so the remote can move ahead of your copy. git fetch downloads the new commits and updates your remote-tracking branches such as origin/main, but it does not touch your files or your current branch. It is the safe way to look at what changed before deciding what to do.

git pull is a shortcut for two steps: it runs git fetch and then merges the fetched branch into the branch you are on. Because it changes your files, it can produce a merge or a conflict.

When both you and the remote have new commits, a normal pull creates an extra merge commit that joins the two lines of history. If you prefer a straight, linear history, use git pull --rebase. It fetches, then replays your own commits on top of the remote's latest commit instead of merging.

git fetch
git log --oneline main..origin/main
git pull --rebase

Look first, then bring the changes in

Sometimes a push fails with a message like rejected ... (non-fast-forward). It means the remote branch has commits that you do not have locally, so Git refuses to overwrite them. Nothing is broken. You just need to bring those commits in first and then push again.

The other thing that stops beginners is signing in. GitHub no longer accepts your account password for Git operations over HTTPS. Instead you create a personal access token in your GitHub settings and paste it where Git asks for a password. The alternative is SSH, where you generate a key pair, keep the private key on your machine and add the public key to GitHub. After that, no password or token is needed on each push.

On a shared project you rarely push straight to main. Instead you work on a branch, push that branch, and ask for it to be merged through a pull request on GitHub. A pull request is a page where teammates can read your changes, comment and approve before anything reaches main.

git switch -c feat/login
git add .
git commit -m "Add login form"
git push -u origin feat/login

Everything before opening the pull request

Once the pull request is merged, switch back to main and run git pull so your local copy includes the merged work.

Finally, a warning about git push --force. It makes the remote branch match yours exactly, discarding any commits on the remote that you do not have. If a teammate pushed work you have not pulled, a force push erases it from the shared history.

Some files in a project should never become part of its history: downloaded dependencies, log files, compiled output, and files holding passwords. A .gitignore file is a plain text file in your repository that lists patterns for the files Git should not track. Once a pattern matches, the file stops showing up in git status and git add . skips it.

Each line is one pattern. Blank lines are skipped, and a line starting with # is a comment. The three patterns you will write most often target a folder, a file extension, or one specific file.

# dependencies
node_modules/

# any log file, in any folder
*.log

# one specific file
.env

A small .gitignore at the root of a web project

Two small symbols give you finer control. A leading ! negates a pattern, which means a file that an earlier line ignored is tracked again. A leading / anchors the pattern to the folder that holds the .gitignore, so it no longer matches in subfolders.

*.log
!keep.log

/build

Ignore all logs except keep.log, and ignore only the build folder at the repo root

Here keep.log is tracked even though *.log comes first, because the later !keep.log line wins. Without the slash, build would also ignore docs/build. With /build, only the top-level folder is skipped.

The .gitignore is a normal file, and you should commit it like any other. Then everyone who clones the project gets the same rules, and nobody on the team accidentally commits node_modules/ or their own log files.

There is one rule that surprises almost every beginner. Ignoring only affects untracked files. If Git is already tracking a file, adding it to .gitignore changes nothing: Git keeps recording its changes. The ignore list is only consulted for files Git has never seen.

To fix an already tracked file, tell Git to forget it while leaving your copy alone. The --cached flag limits the removal to the staging area and the repository, so the file stays in your working folder. Then commit the removal, and the ignore rule takes over from there.

When a file is missing from git status, or surprisingly present, you can ask Git directly. git status --ignored adds a section listing everything currently ignored. When you want to know why, git check-ignore -v <path> prints the exact rule that matched, along with the file and line number it came from.

Ignored files:
  (use "git add -f <file>..." to include in what will be committed)
        .env
        debug.log
        node_modules/
.gitignore:2:*.log	debug.log

Sample output: the last line reads file:line:pattern, then the path

Some junk belongs to your computer or editor, not to the project: .DS_Store from macOS, Thumbs.db from Windows, or .vscode/ settings. Putting these in every project's .gitignore clutters shared rules. Instead, create one personal list and point Git at it with the core.excludesFile setting. It then applies to every repository you use.

git config --global core.excludesFile ~/.gitignore_global

Then put .DS_Store, Thumbs.db and similar lines in ~/.gitignore_global

A .env file usually holds secrets such as database passwords and API keys. The safe order is to add .env to .gitignore before the first commit. The painful order is to commit it first and ignore it later. Because ignoring does nothing for tracked files, the file keeps being tracked, and every earlier commit still contains the secret in history.

Running git rm --cached .env stops future commits from including it, but the old commits keep the content, and anyone who cloned the repository already has a copy. Deleting the secret from history is hard and cannot reach clones, so treat the secret as public.

Everyone makes mistakes while working, so Git gives you several ways to take things back. The right tool depends on where the mistake lives: in your working tree, in the staging area, or already in a commit. We start with the two smallest undo commands, which deal with files that have not been committed yet.

Suppose you changed notes.txt, decided the edit was a bad idea, and want the file back the way it was at the last commit. git restore notes.txt replaces the file in your working tree with the committed version. Your unstaged edits are thrown away.

git status --short
git restore notes.txt
git status --short

The file is clean again after the restore

Sometimes you ran git add on a file too early. git restore --staged notes.txt moves the file out of the staging area, so it will not be part of the next commit. The file itself is not touched: your edits stay in the working tree, just no longer staged.

Once a change is committed, you have more options. Which one is right depends mostly on one question: has the commit been pushed to a shared remote yet?

If you made a typo in the last commit message, or forgot to add a file, you do not need a new commit. Stage whatever is missing, then run git commit --amend. Git replaces the last commit with a corrected one. Because it rewrites that commit (it gets a new hash), only use it while the commit is still local and unpushed.

git add forgotten.txt
git commit --amend -m "Add login form and its styles"

Replaces the last commit instead of adding a new one

git revert <hash> leaves history alone and adds a new commit that does the exact opposite of the chosen one. The bad commit stays in the log, followed by the commit that cancels it. Because nothing is rewritten, teammates who already pulled the old commit can pull the revert without trouble. That makes it the safe choice for shared history.

git log --oneline
git revert 4f9c2ab
git log --oneline

A new commit appears on top; the old one stays

git reset moves your branch backwards, so commits drop off the end of it. It comes in two flavours that differ in what happens to the changes those commits contained. HEAD~1 means one commit before the current one.

Use --soft when the commit was fine in content but you want to redo it, for example to split it or reword it: all your work is waiting in the staging area. Use --hard only when you truly want the commit and its changes gone.

If you reset too far, committed work is usually not lost. git reflog lists every place HEAD has been recently, including commits that are no longer on any branch. Find the hash from before the reset, then move back to it.

git reflog
git reset --hard HEAD@{1}

HEAD@{1} is where HEAD was one move ago

The golden rule is simple: revert for pushed commits, reset only for local ones. Resetting rewrites history, and if others have already based work on those commits, their copies will disagree with yours and cause painful conflicts. Revert simply adds a new commit, so everyone stays in sync.

Almost every Git user makes the same handful of mistakes in their first months. None of them is fatal, and most are easy to fix if you notice early. This section walks through nine of them, starting with three that are about where a commit goes and what goes into it.

You start fixing a bug, then realise you are still on main instead of a feature branch. If you have not committed yet, the fix is easy: git switch -c fix/login-bug creates a new branch at your current position and moves you onto it. Your uncommitted changes come along, and the next commit lands on the new branch, leaving main untouched.

git branch --show-current
git switch -c fix/login-bug
git add app.py
git commit -m "Fix crash when the password is empty"

Check where you are, then branch before committing

If you already committed on main, create the branch first so the commit is safe, then use git cherry-pick to copy it where it belongs, or simply move the branch pointer. The flow below shows the cherry-pick route.

A .env file, a database password or an API key committed to a repository is the most costly beginner mistake. Once a commit is pushed, assume the secret is public: bots scan GitHub for keys within minutes, and deleting the file in a later commit does not remove it from history.

The order of response matters. Rotate the key first, by revoking it at the provider and issuing a new one. Then remove the file from tracking and add it to .gitignore. Rewriting history with a tool such as git filter-repo is a last resort, because it changes every later commit hash for the whole team, and it still does not help once the key has been copied elsewhere.

Dependency folders and generated output can be thousands of files and hundreds of megabytes. They bloat the repository, make every clone slow and create noisy diffs. They can always be rebuilt from your source and lockfile, so they do not belong in Git. Put a .gitignore in the very first commit, because ignoring a file only works for files Git is not yet tracking.

node_modules/
dist/
build/
__pycache__/
.env

A starter .gitignore for the first commit

git rm -r --cached node_modules
git commit -m "Stop tracking node_modules"

Already committed it? Untrack it, keeping the files on disk

The next three mistakes are about working with other people: how you share commits, how often you refresh your copy, and how you describe what you did.

When a normal git push is rejected, Git is protecting you: the remote has commits you do not have. Adding --force tells the remote to throw its version away and use yours. If a teammate pushed work in the meantime, those commits are overwritten on the server, and their next pull becomes a confusing mess.

If a push is rejected, run git pull, resolve anything that comes up, then push again. If you truly must force a private branch, prefer git push --force-with-lease, which refuses to overwrite commits you have not seen.

A commit called update that touches forty files tells nobody anything. You cannot review it, you cannot revert one part of it, and git log becomes useless. Commit small and often, with one logical change per commit, and write a subject line that says what changed.

If you begin work on a stale copy, you may spend an hour editing code that a teammate already changed. The conflict appears only when you finally push, when it is most painful. Pulling at the start of a work session keeps your base current and shrinks the gap that can conflict.

git switch main
git pull
git switch -c feat/profile-page

Update first, then branch

A merge conflict means Git could not decide between two versions of the same lines, so it asks you. Beginners often panic and delete one whole side, which silently throws away a teammate's work or their own. Instead, read both versions and keep the right lines, which is often a mix of the two.

<<<<<<< HEAD
timeout = 30
=======
timeout = 60
retries = 3
&gt;&gt;&gt;&gt;&gt;&gt;&gt; feat/retry

Above the ======= is your side, below is theirs

Here the right answer might keep the longer timeout and the new retries line. Delete the three marker lines, save the file, then git add it and finish with git commit. Run the tests before you do.

Checking out a commit hash instead of a branch puts you in detached HEAD state: HEAD points straight at a commit, not at a branch name. That is fine for looking around. But if you commit there and then switch away, those commits belong to no branch and become hard to find. To keep the work, give it a branch while you are still there.

git checkout 3f9a2c1
git switch -c experiment/old-version

Git warns about detached HEAD; naming a branch saves anything you commit

If you only wanted to look, run git switch main to return. If you already switched away and lost commits, git reflog lists where HEAD has been, so you can find the hash and branch from it.

Every commit records an author. If you never configured your identity, Git either refuses to commit or guesses a name and address from your computer, so history shows a stranger, and GitHub cannot link the commits to your account. Set it once for all repositories.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global --list

Use the same email as your GitHub account

Every Git command you use moves changes between a few places. If you keep that map in your head, the commands stop feeling like a list to memorise. Your edits start in the working tree, move to the staging area when you add them, become a permanent snapshot in the repository when you commit, and reach your teammates on the remote when you push.

Before the first commit, tell Git who you are. The name and email are stamped on every commit you make. The --global flag stores them once for your whole computer, so you only do this a single time.

git config --global user.name "Asha Rao"
git config --global user.email "asha@example.com"

One-time setup, used on every commit afterwards

Then you need a repository to work in. You either turn an existing folder into one, or copy one that already lives somewhere else.

git init
git clone https://github.com/example/notes.git

Start from scratch, or copy an existing project

Most days you repeat one small loop: check what changed, choose what belongs together, and record it. Run git status first and often. It tells you which files are modified, which are staged and which Git has never seen.

git status
git add notes.txt
git commit -m "Add shopping list notes"

One pass through the loop

Once you have a few commits, you will want to look at them. Four commands cover almost every question. The two diff commands differ only in which areas they compare, which is where beginners usually trip.

git log --oneline --graph
git diff
git diff --staged
git show a1b2c3d

Replace a1b2c3d with a hash from your own log

A branch is a separate line of work, so you can try something without disturbing the main line. The usual life of a branch is short: create it, commit on it, merge it back, then delete it.

Branches live on your computer until you share them. The remote is the copy on GitHub or another server. Git never talks to it behind your back: you decide when to download and when to upload.

git switch -c add-search
git commit -am "Add search box"
git push -u origin add-search

After -u, a plain git push or git pull works on this branch

Undoing in Git depends on how far the change has travelled. A change that is only in your working tree is easy to drop. One that is staged can be unstaged. One that is already committed is best undone with a new commit if other people have it.

The last piece is keeping files out of Git. A .gitignore file lists patterns for things like build output, secrets and editor folders. Ignore rules only affect files Git is not tracking yet, so a file you already committed needs to be untracked first.

# .gitignore
node_modules/
*.log
.env

One pattern per line

git rm --cached config.local
git check-ignore -v debug.log

Stop tracking a file but keep it on disk, then ask which rule ignores a path

Try each question before opening the answer. They ask you to predict what Git will do, not to repeat definitions.

• Changes move working tree → staging (git add) → repository (git commit) → remote (git push), and git add alone never commits.
• Run git status and git diff --staged before each commit, and keep every commit to one logical change with an imperative subject line.
• A branch is just a movable pointer to a commit, so creating and switching branches is cheap; merge it back when the work is done.
• git pull is fetch plus merge; if a push is rejected, pull first and avoid force pushing over shared work.
• .gitignore only affects untracked files, so use git rm --cached for tracked ones and rotate any secret that was ever committed.
• Use git revert for pushed commits, reset only for local ones, and git reflog to recover after a mistake.