Git & GitHub Tutorial (Beginner’s Guide)

What is Git? Git is a distributed version control system that tracks changes in code and lets multiple
developers work together seamlessly. Each developer has a complete copy of the project history on their
machine 1 2 . This means you can commit changes, create branches, and merge code offline, then sync
later. Git keeps a full history (like backups) on every computer, so it is fast and reliable 1 3 .

What is GitHub? GitHub is an online platform that hosts Git repositories. It provides cloud storage for
your code and tools for collaboration 2 . Using GitHub alongside Git lets teams share projects, review
code, and manage projects together. Features like pull requests, issue tracking, and project boards make
teamwork easier 4 5 . In practice, you work on your local Git repo on Windows (using Git Bash or CMD),
then push changes to GitHub so others can see and integrate them 3 2 .

• Key reasons to use Git/GitHub: track all changes, revert mistakes, work on branches, collaborate with
others, and keep backups of code in the cloud 1 2 .

Installing Git on Windows

1. Download Git: Go to git-scm.com/downloads and choose the Windows installer 6 .
2. Run the installer: Follow prompts. Accept defaults (Git Bash will be installed).
3. Verify Installation: Open Git Bash or Windows CMD and run:

git --version

You should see the Git version. If not, ensure the PATH was added during install.
4. Configure your identity: Set your name/email (only needed once). In Bash/CMD:

git config --global user.name "Your Name"

git config --global user.email "[email protected]"

This links your commits to you.

Tip: On Windows, use Git Bash (installed with Git) or CMD. Git commands work the same; many developers
prefer Git Bash for Unix-like commands.

Basic Git Workflow

Git organizes work into three main areas 7 :

• Working Directory: Your current files on disk (where you edit code).
• Staging Area (Index): A “staging” space where you prepare changes for commit.

1
• Local Repository: The .git folder storing the full commit history.

• Initialize a repository: In a project folder, run:

git init

This creates a new Git repository 8 . Now Git will track changes in this folder.

• Check status: To see what’s changed, use:

git status

This shows new, modified, or staged files. It helps you know what will be committed 9 .

• Make a change: Create a file (e.g., README.md ) or edit code. For example:

echo "# My Project" > README.md

Now git status will show README.md as untracked (new file).

• Stage changes: Add files to the staging area with git add . For example:

git add README.md

This tells Git, “include this file in the next commit.” You can stage multiple files:

git add file1.txt file2.txt

or stage all changes with:

git add .

The git add command takes changes from the working directory and adds them to the
staging area 10 .

• Commit changes: Record a snapshot with:

git commit -m "Add initial README"

2
 The -m flag gives a commit message. This creates a new commit containing the staged changes
11 . Think of a commit as a saved checkpoint of your project.

• View history: To see past commits, use:

git log --oneline

This lists commits (most recent first) 12 . Each line shows a commit ID and message. Good commit
messages (brief and descriptive) are best practice.

Example: If you later add more text to README.md , you would again git add README.md and git
commit -m "Update README" to save that change.

Inspecting and Undoing Changes

• Check differences: Before committing, you can see what changed with:

git diff

This shows line-by-line changes in files.

• Remove from staging: If you accidentally added a file but decide not to commit it yet, you can
unstage it:

git reset HEAD filename

This moves the change out of the staging area. (On newer Git versions, git restore --staged
filename also works.) This does not delete your work, it just “unstages” it.

• Undo a commit: To undo commits, two main commands are:

• git revert : Safely creates a new commit that undoes changes from a previous commit.

• git reset : Can move the HEAD to an earlier commit (discarding later commits). For example:

git reset --hard HEAD~1

This command resets the branch to one commit earlier and discards all changes in your working
directory and staging area 13 14 . Use --hard with caution, only when you really want to
eliminate changes 15 14 . (Without --hard , git reset defaults to --mixed , which keeps
changes in your files but unstages them.)

3
 • Example: If you made a commit and immediately realize it’s wrong, git reset --hard HEAD~1
will erase that commit as if it never happened 13 15 . But remember this is destructive locally.

Stashing Changes
Sometimes you start editing but need to switch to another branch or task without committing unfinished
work. Git stash lets you temporarily shelve your uncommitted changes 16 :

• To save (stash) current changes:

git stash

This records your uncommitted (staged and unstaged) changes and then cleans your working
directory to match the last commit 17 . It’s like putting changes in a locker.

• To view stashes, use:

git stash list

• To apply the latest stash and remove it from the stash list:

git stash pop

or keep it in the stash (apply without removing):

git stash apply

After popping, Git reapplies the changes to your working directory 18 .

• To clear all stashes:

git stash clear

Use-case: You have edits in progress but must urgently switch to main to fix a bug. Run git stash ,
switch branches, fix/commit, then return and run git stash pop to continue where you left off 16 18 .

Working with GitHub (Remotes)

1. Create a GitHub repository: On GitHub, create a new empty repository (give it a name). This will
provide a remote URL like https://github.com/you/myrepo.git .

4
 2. Add a remote: In your local Git repo, link the remote URL. The convention is to name the primary
remote origin :

git remote add origin https://github.com/you/myrepo.git

This tells Git where the GitHub repo lives.

3. Push local changes to GitHub: Upload your commits to GitHub:

git push -u origin main

(Use master if your default branch is named master.) This sends your main branch to the
origin remote. The -u sets upstream tracking so future git push or git pull will default
to this remote/branch.

4. Clone an existing repo: To work on someone else’s or your own repo, you can clone it:

git clone https://github.com/you/myrepo.git

This copies the entire repository to your computer 19 .

Note: On Windows, git push and git pull behave the same in Git Bash or CMD. When pushing, you
may be asked for your GitHub username/password (or use SSH keys for authentication).

Branches
Branches in Git let you develop features or fixes in isolation 20 . The default branch is usually main (or
master ).

• Create a new branch:

git branch feature-x

or (shortcut)

git checkout -b feature-x

This creates and switches to feature-x .

• Switch branches:

5
 git checkout feature-x

This makes your working directory reflect that branch’s HEAD.

• List branches:

git branch

shows all local branches, marking the current one with * .

• Merge branches: After finishing work on a branch, switch back to main and merge:

git checkout main

git merge feature-x

This integrates the commits from feature-x into main . Git automatically does a “merge
commit” if needed 21 .

• Push a branch: To share a branch on GitHub, push it:

git push -u origin feature-x

Example: You start a bug fix on branch bugfix , commit changes there, then merge back into main when
done. If Git can’t auto-merge, you’ll get a merge conflict (see below).

Forks and Upstream

• Fork: On GitHub, “forking” a repo means creating your own copy on GitHub (private to you) 22 . This
lets you experiment freely. Forks create a separate remote repository under your GitHub account.

• Clone a fork: After forking on GitHub, clone it to your machine:

git clone https://github.com/yourusername/forked-repo.git

This automatically sets origin to your fork.

• Upstream remote: To stay updated with the original repo (the “upstream”), add it as another
remote:

6
 git remote add upstream https://github.com/originaluser/original-repo.git

Now origin is your fork, and upstream is the original project 23 24 .

• Sync with upstream: Periodically fetch and merge:

git fetch upstream

git merge upstream/main

or rebase your work onto it:

git rebase upstream/main

This updates your local and then you can push to your fork. Keeping in sync avoids falling behind on
changes.

Why: If you contribute to an open-source project, fork it, clone your fork, then use upstream to
incorporate new changes from the main project 22 23 .

Pull Requests
A Pull Request (PR) is a GitHub feature to propose merging your changes into someone else’s repository. It
provides a discussion and review interface 5 .

• Create a PR: Push your feature branch to GitHub, then on GitHub click “Compare & pull request.”
Select the base (e.g., main ) and the head (your branch). Write a description and submit.

• Never commit on main : Best practice is to make all changes on branches (even your own repo’s
branches), then open a PR. This keeps main stable 5 .

• Review and merge: Team members review the PR. Once approved, you (or project maintainers) click
“Merge”. This merges the commits into the target branch (often main ).

• Amend or remove commits: If you find mistakes in a PR, you can fix them in your branch and force
push:

git commit --amend

git push --force

This updates the PR. Use force push carefully; it rewrites history that others may have.

Pull requests help with code review and discussion before changes go into the official project 5 .

7
Squashing Commits and Rebasing
Sometimes you want a clean history. Git offers rebase and squash:

• Rebase ( git rebase ): Reapplying commits onto a new base 25 . Common use: update a feature
branch with the latest main :

git checkout feature-x

git fetch origin
git rebase origin/main

This moves your feature-x commits to appear on top of main , creating a linear history 26 .
Rebasing rewrites history (creates new commits) but keeps the changes. It is useful for integrating
updates and making a clean history before merging 26 25 .

• Interactive rebase (squash): To combine multiple commits into one, use:

git rebase -i HEAD~3

This opens an editor listing the last 3 commits. Change pick to squash (s) for commits you
want to fold into the previous one. For example, combining 3 tiny commits into 1 bigger commit 27 .
After saving, Git combines them, making the history look like your work was done in a single, clean
commit 27 .

• Why squash? It hides minor fixup commits and presents the feature as one neat unit 27 . Others
see a simpler history.

• Note: Interactive rebase is powerful but use with care. It rewrites commit hashes. Never rebase
commits that have been pushed to a shared branch (unless you coordinate with others).

Resetting Commits
Git has three reset modes 13 :

• Soft reset ( --soft ): Moves HEAD to a previous commit but keeps changes staged.
• Mixed reset (default): Moves HEAD and unstages changes (keeps them in working directory).
• Hard reset ( --hard ): Discard all changes in the specified commits. E.g.,

git reset --hard HEAD~2

This moves HEAD two commits back and erases all intervening changes from your files 13 15 .

8
Warning: git reset --hard can permanently delete work. Use it only when you want to throw away
uncommitted changes 15 14 . It’s useful to quickly revert to a previous state on a local branch 13 14 .

Merge Conflicts and Resolution

A merge conflict happens when Git cannot automatically reconcile changes from two branches 28 . For
example, if two branches edit the same line in a file differently, Git stops merging and marks the conflict.

• Identifying conflicts: After a failed git merge or git pull , Git will list conflict markers in files.
git status will show “Unmerged paths.”

• Resolving conflicts: Manually edit the file to fix the conflict. The file will have sections like:

<<<<<<< HEAD
your change
=======
incoming change
>>>>>>> feature-branch

Decide which code to keep (or combine), then remove the markers. Save the file.

• Finalize resolution: After editing, run:

git add conflicted-file

git commit

This records the merge with your conflict resolutions.

• Conflict tools: You can also use GUI tools or IDE merge tools to help. But the basic idea is the same:
reconcile differences and commit.

In short: Conflicts require human intervention. Git helps by pointing out conflicts; you must resolve them to
complete the merge 28 .

Summary of Key Git Commands

• Setup and Status:
• git init – create a new Git repo 8 .
• git clone <url> – copy an existing repo 19 .

• git status – show current state (tracked changes, etc.) 9 .

• Tracking Changes:

9
 • git add <file> – stage changes for commit 10 .
• git commit -m "msg" – save staged changes into a new commit 11 .

• git log – view commit history 12 .

• Undo Changes:

• git reset HEAD <file> – unstage a file (remove from staging).

• git revert <commit> – create a new commit that undoes a past commit.

• git reset --hard <commit> – reset to a commit and discard all changes 13 .

• Working with Remotes:

• git remote add origin <url> – link local repo to a remote repo.
• git push – upload commits to remote 29 .

• git pull – fetch and merge changes from remote.

• Branching & Merging:

• git branch <name> – create a new branch.

• git checkout <branch> – switch branches. (Or git switch .)

• git merge <branch> – merge another branch into the current one.

• Stashing:

• git stash – save and clear uncommitted changes 16 .

• git stash pop – reapply stashed changes 18 .

• Syncing Forks/Upstream:

• git remote add upstream <original-repo-url> – add upstream remote 23 24 .

• git fetch upstream – fetch changes from upstream 30 .

• git merge upstream/main – merge upstream updates into your branch 31 .

• Rebase & Squash:

• git rebase <branch> – rebase current branch onto <branch> 25 .

• git rebase -i <base> – interactively edit/squash commits. Squashing combines commits
(making history linear and clean) 27 .

Each command is used in Git Bash or Windows CMD. Always double-check with git status to see what
state you’re in before and after each step 9 .

10
Best Practices
• Branch for features: Don’t work directly on main . Create descriptive branches (e.g. feature-
login ) 20 .
• Commit often: Make small, logical commits with clear messages.
• Pull before push: git pull (or git fetch then git merge ) often to avoid conflicts.
• Use .gitignore: Exclude files you never want in Git (e.g. binaries, IDE configs).
• Review changes: Use git diff and git status to review before committing or pushing.
• Backup: Pushing to GitHub acts as a backup. Always push important branches to avoid losing work.

By following these steps and commands, you can manage your code with Git on Windows (CMD or Git Bash)
and collaborate using GitHub. This workflow – initializing a repo, making commits, creating branches, and
using pull requests – covers most real-world needs for version control 1 5 .

Sources: Git concepts and commands are based on Git documentation and tutorials 8 16 25 13 28 23

5 , adapted for beginners. Each command above is demonstrated or explained with real examples.

1 3 What is a distributed version control system?

https://about.gitlab.com/topics/version-control/benefits-distributed-version-control-system/

2 4 What Is GitHub? Uses and Getting Started - Forage

https://www.theforage.com/blog/skills/what-is-github

5 22 Basic Git Commands | Atlassian Git Tutorial

https://www.atlassian.com/git/glossary

6 7 8 9 10 11 12 19 20 21 29 5 Minutes Guide for GIT Basics and its Commands | by Fibonalabs |

Medium
https://medium.com/@fibonalabsdigital/5-minutes-guide-for-git-basics-and-its-commands-43d0cbd6665c

13 14 15 Git Reset | Hard, Soft & Mixed | Learn Git

https://www.gitkraken.com/learn/git/git-reset

16 17 18 git stash - Saving Changes | Atlassian Git Tutorial

https://www.atlassian.com/git/tutorials/saving-changes/git-stash

23 24 30 31 Git Upstreams and Forks: A Complete How-To | Atlassian Git Tutorial

https://www.atlassian.com/git/tutorials/git-forks-and-upstreams

25 26 27 git rebase | Atlassian Git Tutorial

https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase

28 Git merge conflicts | Atlassian Git Tutorial

https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts

11