BrainBit Infotech Teaching · Elective

Master Git & GitHub

Version control is the professional developer's time machine, safety net, and teamwork engine — learn it once, use it every day.

🌿 6 topics 🧪 4 tests 🎓 1 final exam 💻 works offline
Press → or Space to begin · F fullscreen · O overview
The one thing everyone confuses

Git vs GitHub

GitGitHub
Installed softwareA website
Works offlineNeeds the internet
Tracks changes in your local foldersLets you share & review code with others
Created by Linus Torvalds, 2005Launched separately, acquired by Microsoft, 2018
Free and open-sourceFree for public repos, paid plans for private/teams
Like a diary you keep at homeLike a library you share with the world
🧠
Git is the tool. GitHub is the platform. You can use Git with no GitHub at all — but together is what professionals do daily (GitLab/Bitbucket also use Git).
The road ahead

6 topics + 4 tests + final exam

🕰️

1 · Why VC

The problem version control solves

⌨️

2 · Core Commands

init, add, commit, log

🌿

3 · Branching

Isolate work, merge safely

☁️

4 · Remotes

push, pull, fetch, clone

🐙

5 · GitHub

Repos, auth, README, Markdown

⚡

6 · Conflicts

Read, resolve, prevent

Four of the six topics end in a runnable terminal simulation + a 15-question test (8 command + 7 concept) on a 15-minute timer. Then a 30-question final exam.

One-time setup

Install & configure Git

terminal
$ # Check Git is installed (download from git-scm.com if not)
$ git --version
>> git version 2.43.0

$ # Configure your identity — required ONCE per computer
$ git config --global user.name "Priya Sharma"
$ git config --global user.email "priya@example.com"

$ # Use VS Code as the editor, and 'main' as the default branch
$ git config --global core.editor "code --wait"
$ git config --global init.defaultBranch main

$ # Verify
$ git config --list
>> user.name=Priya Sharma
>> user.email=priya@example.com
>> init.defaultBranch=main
🔑
Git signs every commit with this name & email. Use the SAME email as your GitHub account so commits show on your profile.
01
Topic 1

Why Version Control?

Before any command — the problem every developer hits without it, and what Git actually buys you.

Concept · a familiar disaster

The problem

Downloads/
assignment.docx
assignment-v2.docx
assignment-v2-edited.docx
assignment-v2-edited-FINAL.docx
assignment-v2-edited-FINAL-ACTUALLY-FINAL.docx
assignment-v2-edited-FINAL-ACTUALLY-FINAL-2.docx

$ # ...which one did the professor grade?
$ # ...which one has your partner's latest changes?
$ # ...where did the paragraph you wrote at 2am go?
😩
Now multiply by 10 developers emailing ZIP files — nobody knows the real latest version. That's what Git solves.
Concept · same project, two workflows

Without Git vs With Git

folder chaos vs. one folder
WITHOUT GIT                          WITH GIT
------------------------------       ------------------------------
project-v1/                          project/
project-v2/                            .git/            (full history)
project-v2-fixed/                       index.html
project-FINAL/                          style.css
project-FINAL-USE-THIS/                 app.js
project-FINAL-USE-THIS-2/
                                      $ git log --oneline
$ # which folder is "current"?       >> a1b2c3d Fix navbar bug
$ # copy-paste merges by hand        >> 9f8e7d6 Add contact form
$ # no record of WHO changed WHAT    >> 4c5b6a7 Initial commit

One folder, one .git history. Every past version is one command away — nothing is ever truly lost or renamed into confusion.

Concept · the payoff

What Git gives you

🕰
Time machine — jump back to any earlier version of any file, any day.
🧪
Safe experimentation — try a risky change on a branch; delete it if it fails, nothing else is touched.
👥
Team collaboration — many developers edit the same project without emailing files back and forth.
🔍
Blame tracker — see exactly who changed which line, when, and why (the commit message).
☁️
Backup — push to GitHub and your entire history survives a dead laptop.
🚀
Deployment history — know exactly what code is live, and roll back instantly if a release breaks.
02
Topic 2

Core Git Commands

init, status, add, commit, log, and the one file you should write before any of them: .gitignore.

Concept · how a change travels

The three areas

how every change moves
Working Directory  --(git add)-->  Staging Area  --(git commit)-->  Repository
   (your edits)                    (what's next)                    (saved forever)
✍️
Think of it like writing an essay: the Working Directory is your rough draft, Staging is the pages you've decided go in this submission, and a commit is handing in that exact draft — permanently, with your name on it.
Concept · start tracking

git init

terminal
$ mkdir my-portfolio
$ cd my-portfolio
$ git init
>> Initialised empty Git repository in /home/priya/my-portfolio/.git/
init vs clone: init = brand-new local repo; clone = copy an existing GitHub repo.
Concept · see it, stage it

git status & git add

terminal
$ git status
>> Untracked files:
>>   (use "git add <file>..." to include in what will be committed)
>>         index.html      <-- shown in red

$ git add index.html
$ git status
>> Changes to be committed:
>>         new file:   index.html      <-- now shown in green

$ git add .          # stage every changed file in this folder
$ git add *.js       # stage only JavaScript files
$ git restore --staged index.html   # oops — unstage it (keeps your edits)
Red = untracked / not staged. Green = staged and ready to commit. git status is the command you should run constantly.
Concept · save a snapshot

git commit

terminal
$ git add .
$ git commit -m "Add initial project files"
>> [main (root-commit) a1b2c3d] Add initial project files
>>  3 files changed, 42 insertions(+)

$ git commit -am "Fix navbar bug"   # stage all TRACKED changes + commit, in one step
$ git commit --amend -m "Add initial project files (typo fixed)"   # rewrite the last commit
💬
BAD messages: fix, wip, update — tell nobody anything. GOOD messages: Add user authentication, fix(api): handle null response — specific about what changed.
Concept · read the history

git log

terminal
$ git log
>> commit a1b2c3d4e5f6...
>> Author: Priya Sharma <priya@example.com>
>> Date:   Wed Jul 8 10:22:04 2026
>>
>>     Add initial project files

$ git log --oneline
>> a1b2c3d Add initial project files

$ git log --oneline --graph --all
>> * a1b2c3d (HEAD -> main) Add initial project files

$ git show a1b2c3d
>> # full diff of exactly what changed in that one commit

--oneline compresses each commit to a hash + message; --graph --all draws the branch structure; git show <hash> shows the full diff of one commit.

Concept · tell Git what to skip

.gitignore

.gitignore
$ touch .gitignore

# --- Python / Django ---
venv/
__pycache__/
*.pyc
.env

# --- Node / MERN ---
node_modules/
dist/
build/

# --- OS / editor ---
.DS_Store
Thumbs.db
.vscode/
🔒
Create and commit .gitignore FIRST — before anything else — so secrets and huge folders never enter history.
🔌 Simulation · run it in your own terminal

Your first repository

terminal
$ mkdir devcard && cd devcard
$ git init
>> Initialised empty Git repository

$ echo 'node_modules/' >> .gitignore
$ touch index.html style.css README.md

$ git status
>> Untracked files: .gitignore  index.html  style.css  README.md

$ git add .
$ git commit -m "Initial commit: project setup"
>> [main (root-commit) a1b2c3d] Initial commit: project setup
>>  4 files changed

$ git log --oneline
>> a1b2c3d (HEAD -> main) Initial commit: project setup

Every real project starts this way: init, ignore the junk, stage, commit, verify with log. Run it yourself before the test.

03
Topic 3

Branching

Isolate risky work on its own timeline, then bring it back together safely.

Concept · a parallel timeline

Why branches

📄
Resume copy — before you try a new résumé format, you duplicate the file. If the new layout looks bad, you throw away the copy and the original is untouched. A branch is that duplicate, but for your whole project.
🌌
Parallel universe — a branch lets you live in an alternate timeline where you've already made a risky change. If that universe turns out fine, you merge it back into reality (main). If not, you delete it and nothing was ever affected.
Professional rule: NEVER commit directly to main. Every change — even a tiny one — gets its own branch, then a merge.
Concept · branches are just pointers

The pointer model

how a branch really works
Step 1 — main has three commits:

  main:            A---B---C

Step 2 — git checkout -b feature/login
  (a new pointer "feature/login" is created at C; HEAD moves to it)

  main:            A---B---C
  feature/login:            C  (HEAD)

Step 3 — two commits made while on feature/login:

  main:            A---B---C
  feature/login:            \
                              D---E  (HEAD)

Step 4 — merge feature/login back into main:

  main:            A---B---C-------F
                             \     /
  feature/login:              D---E
📌
A branch is nothing but a movable pointer to a commit. Creating one is instant and cheap — Git doesn't copy any files.
Concept · create, move, rename, remove

git branch / git switch

terminal
$ git branch
>> * main

$ git branch feature/login
>>   # creates the pointer — does NOT switch to it

$ git checkout feature/login
>> Switched to branch 'feature/login'

$ git switch feature/login
>> Switched to branch 'feature/login'   # switch = modern, safer alternative to checkout

$ git branch -m old-name new-name
>>   # rename a branch

$ git branch -d feature/login
>>   # delete — SAFE, refuses if not yet merged

$ git branch -D feature/login
>>   # force-delete, even if unmerged — use with care

$ git branch -a
>>   # list every branch, including remote-tracking ones
git branch <name> only creates a pointer. git checkout/git switch is the command that actually moves HEAD onto it.
Concept · create and switch in one step

checkout -b

terminal
$ git checkout -b feature/contact-form
>> Switched to a new branch 'feature/contact-form'

$ git switch -c feature/contact-form
>> Switched to a new branch 'feature/contact-form'   # -c = create; identical result to checkout -b

$ touch contact.html
$ git add . && git commit -m "Add contact form markup"
>> [feature/contact-form 7f8e9d0] Add contact form markup

$ echo "form { border: 1px solid #ccc; }" >> style.css
$ git add . && git commit -m "Style the contact form"
>> [feature/contact-form 9a1b2c3] Style the contact form
⚡
One command instead of two: -b/-c creates the branch AND checks it out immediately, so you never accidentally commit on main.
Concept · bringing branches back together

git merge

two kinds of merge
Fast-forward (main hasn't moved since branching):

  main:            A---B---C
  feature:                   \
                               D---E

  after "git merge feature" on main:

  main:            A---B---C---D---E   (main's pointer just slides forward)

Three-way merge (main moved on too — needs a new commit):

  main:            A---B---C-------F
                             \     /
  feature:                    D---E

  F is a new "merge commit" — it has TWO parents (C and E)

$ git checkout main
>> Switched to branch 'main'

$ git merge feature/contact-form
>> Updating a1b2c3d..9a1b2c3
>> Fast-forward
>>  contact.html | 1 +
>>  style.css    | 1 +

$ git branch -d feature/contact-form
>> Deleted branch feature/contact-form (was 9a1b2c3).
Merge vs rebase: this course always uses merge; rebase is an intermediate topic.
Concept · conventions professionals follow

Branch naming conventions

PrefixUsed forExample
feature/New functionalityfeature/login
fix/Non-urgent bug fixfix/navbar-overlap
hotfix/Urgent production fixhotfix/payment-crash
release/Preparing a releaserelease/v2.1.0
chore/Maintenance, deps, configchore/update-dependencies
docs/Documentation onlydocs/api-readme
🏷️
Consistent prefixes let teammates (and CI pipelines) instantly tell what a branch is for, just from its name.
🔌 Simulation · run it in your own terminal

Branch & merge

terminal
$ git checkout -b feature/about
>> Switched to a new branch 'feature/about'

$ touch about.html
$ git add . && git commit -m "Add about page"
>> [feature/about d4e5f6a] Add about page

$ git checkout main
>> Switched to branch 'main'

$ git merge feature/about
>> Updating a1b2c3d..d4e5f6a
>> Fast-forward

$ git branch -d feature/about
>> Deleted branch feature/about (was d4e5f6a).

Branch, commit, switch back, merge, clean up — the exact rhythm you'll repeat for every feature. Run it yourself before the test.

04
Topic 4

Remote Repositories

Your local history is safe on your machine — a remote is how it reaches GitHub, your teammates, and a backup that survives a dead laptop.

Concept · two copies of the same history

Local vs remote

where your history actually lives
Your laptop        --(git push)-->   GitHub               --(git clone)-->   Colleague's laptop
  LOCAL REPO       <--(git pull)---   REMOTE REPO                              LOCAL REPO (their own copy)
☁️
A remote is just another copy of the repo — usually on GitHub. push sends your commits there; pull brings theirs to you; clone gives a whole new person their own full copy.
Concept · naming the other copy

git remote

terminal
$ git remote add origin https://github.com/priya/devcard.git
>>   # links your local repo to a remote, nicknamed "origin"

$ git remote -v
>> origin  https://github.com/priya/devcard.git (fetch)
>> origin  https://github.com/priya/devcard.git (push)

$ git remote set-url origin https://github.com/priya/devcard-renamed.git
>>   # updates the URL "origin" points to, e.g. after a repo rename

$ git remote remove origin
>>   # unlinks the remote — your local history is untouched
origin is just a convention, not a keyword — it's the default nickname Git gives the first remote you add.
Concept · send your commits upstream

git push

terminal
$ git push -u origin main
>> Enumerating objects: 6, done.
>> Writing objects: 100% (6/6), 1.02 KiB | 1.02 MiB/s, done.
>> To https://github.com/priya/devcard.git
>>  * [new branch]      main -> main
>> Branch 'main' set up to track 'origin/main'.

$ git push
>>   # -u only needed ONCE — after that, plain "git push" remembers where

$ git push origin feature/login
>>   # push a specific branch explicitly
⚠️
git push --force overwrites remote history and can destroy your team's work. Never force-push shared branches; use git revert to undo pushed commits.
Concept · bring their commits to you

git pull & git fetch

terminal
$ git pull origin main
>> Updating a1b2c3d..9f8e7d6
>> Fast-forward
>>  README.md | 3 +++
>>  1 file changed, 3 insertions(+)

$ git fetch origin
>>   # downloads new commits — does NOT touch your working files yet

$ git diff main origin/main
>>   # review exactly what the remote has that you don't

$ git merge origin/main
>>   # now bring those reviewed changes into your local main

pull = fetch + merge. Pros fetch first, review, then merge.

Concept · get your own full copy

git clone

terminal
$ git clone https://github.com/priya/devcard.git
>> Cloning into 'devcard'...
>> remote: Enumerating objects: 6, done.
>> Receiving objects: 100% (6/6), done.

$ git clone https://github.com/priya/devcard.git my-folder-name
>>   # clone into a custom folder name instead of the repo's default name

$ cd devcard
$ # install dependencies for your stack, then you're ready to work
Clone downloads the FULL history — every commit, branch, and tag — not just the latest files. It also sets up "origin" for you automatically.
Concept · the rhythm professionals repeat

Daily team workflow

#Step
1git pull origin main — start from the latest code
2git checkout -b feature/x — create your branch
3Code the change
4git add . — stage it
5git commit -m "..." — save a snapshot
6Repeat steps 3–5 as needed
7git push -u origin feature/x — send it to GitHub
8Open a Pull Request for review
9Merge the PR into main
10Delete the feature branch — locally and on GitHub
🔁
This ten-step loop is what a professional developer does for nearly every single change, from a tiny typo fix to a major feature.
05
Topic 5

GitHub Basics

Creating repos, connecting them to your local machine, authenticating safely, and writing a README that makes a good first impression.

Concept · the six clicks that matter

Create a repo on GitHub

StepWhat to do
1Click "New" on GitHub to start a repository
2Name it lowercase-with-hyphens, e.g. my-portfolio
3Add a short description
4Choose Public or Private visibility
5Do NOT initialize with a README (if a local repo already exists)
6Click "Create repository", then copy the HTTPS URL
⚠️
Initializing with a README when you already have a local repo creates two unrelated histories that clash on the first push. Only let GitHub add a README when starting completely fresh.
Concept · two ways to link them

Connect local ↔ GitHub

terminal
Scenario A — you already have a local repo:

$ git remote add origin https://github.com/priya/devcard.git
$ git branch -M main
$ git push -u origin main
>> Branch 'main' set up to track 'origin/main'.

Scenario B — starting fresh from GitHub:

$ git clone https://github.com/priya/devcard.git
>> Cloning into 'devcard'...
$ cd devcard
$ # "origin" is already configured — just add files and commit
Scenario A is "local-first" (you coded, now you publish). Scenario B is "GitHub-first" (repo existed, you're joining it). Both end with the same linked local + remote.
Concept · proving it's really you

Auth: HTTPS token vs SSH

HTTPS + tokenSSH key
SetupGenerate a Personal Access Token on GitHubGenerate a key pair once with ssh-keygen
Each pushUsername + token (unless cached)Nothing — the key handles it silently
Best forQuick start, shared/lab computersYour own machine, daily use
Remote URLhttps://github.com/you/repo.gitgit@github.com:you/repo.git
terminal
$ ssh-keygen -t ed25519 -C "you@example.com"
>> Generating public/private ed25519 key pair...

$ cat ~/.ssh/id_ed25519.pub
>> ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... you@example.com

$ # paste that key into GitHub Settings -> SSH and GPG keys -> New SSH key

$ ssh -T git@github.com
>> Hi priya! You've successfully authenticated, but GitHub does not provide shell access.

$ git remote set-url origin git@github.com:priya/devcard.git
GitHub removed password-over-HTTPS logins — it's always a token or an SSH key now, never your account password.
Concept · the first thing anyone reads

Professional README.md

README.md
# DevCard

> A one-page developer portfolio built while learning Git & GitHub.

## Features
- Responsive layout
- Dark / light theme toggle
- Contact form

## Tech Stack
- HTML5, CSS3, JavaScript

## Getting Started
```
$ git clone https://github.com/you/devcard.git
$ cd devcard
$ # open index.html in your browser
```

## Author
Your Name — [GitHub](https://github.com/you)
📝
A README is a sales pitch: title, one-line tagline, what it does, what it's built with, how to run it, who made it. Write it before anyone else looks at your repo.
Concept · the syntax behind every README

Markdown reference

SyntaxMeaning
# / ##Heading / subheading
**bold**Bold text
*italic*Italic text
`code`Inline code
``` fenced ```Multi-line code block
[link](url)Hyperlink
![alt](url)Image
- itemBullet list
> quoteBlockquote
---Horizontal rule
📄
GitHub renders every README.md automatically on the repo's front page — this same syntax also works in issues, pull requests, and comments.
🔌 Simulation · run it in your own terminal

Push to GitHub

terminal
$ git remote add origin https://github.com/priya/devcard.git
$ git remote -v
>> origin  https://github.com/priya/devcard.git (fetch)
>> origin  https://github.com/priya/devcard.git (push)

$ git branch -M main
$ git push -u origin main
>> Writing objects: 100% (6/6), done.
>> To https://github.com/priya/devcard.git
>>  * [new branch]      main -> main
>> Branch 'main' set up to track 'origin/main'.

Link the remote, rename to main, push with -u to set the tracking relationship — the exact sequence every new project needs once. Run it yourself before the test.

06
Topic 6

Resolving Merge Conflicts

The one moment Git can't decide for you — read the markers, choose the code, and move on with confidence.

Concept · why Git sometimes gets stuck

What causes a conflict

1️⃣
Two branches each edit the same line of the same file, differently.
2️⃣
Someone runs git merge to bring the two histories together.
3️⃣
Git compares both versions and can't decide which line should win.
4️⃣
Git pauses the merge and drops conflict markers into the file for a human to resolve.
📄
Like two people editing the same paragraph of a Google Doc at the same time while offline — when they reconnect, someone has to look at both versions and decide what the final paragraph says. A merge conflict is that exact situation, just for code.

Conflicts are normal. Resolving them is a skill.

Concept · manufacture a conflict on purpose

Create one to practise

terminal
$ git checkout main
$ echo 'nav background: blue;' > style.css
$ git add . && git commit -m "Blue navbar"

$ git checkout -b feature/green
$ echo 'nav background: green;' > style.css
$ git add . && git commit -m "Green navbar"

$ git checkout main
$ echo 'nav background: purple;' > style.css
$ git add . && git commit -m "Purple navbar"

$ git merge feature/green
!! Auto-merging style.css
!! CONFLICT (content): Merge conflict in style.css

Both main and feature/green changed the SAME line of style.css after they split apart — Git has no way to guess which colour you actually want.

Concept · decode the file Git leaves behind

Reading the markers

style.css
<<<<<<< HEAD
nav background: purple;       (your current branch — main)
=======
nav background: green;        (incoming branch — feature/green)
>>>>>>> feature/green
✂️
Delete ALL THREE marker lines and keep the code you want — one side, both, or a brand-new value.
Concept · the manual, editor-free way

Resolve in the terminal

#Step
1git status — see which file(s) are in conflict
2Open the conflicted file in your editor
3Find the <<<<<<< / ======= / >>>>>>> marker blocks
4Decide which side to keep — yours, theirs, or a rewrite
5Edit the file — delete ALL marker lines, keep only the code you chose
6Save the file
7git add <file> — mark this file as resolved
8Repeat steps 2–7 for every other conflicted file
9git commit — completes the merge
terminal
$ git status
>> both modified:   style.css

$ code style.css
$ # delete the markers, keep the colour you want, save the file

$ git add style.css
$ git commit
>> [main e7f8a9b] Merge branch 'feature/green'
Concept · one click instead of manual deletes

Resolve in VS Code

📍
Accept Current Change — keeps only your side (HEAD), discards the incoming code.
📥
Accept Incoming Change — keeps only the branch being merged in, discards your version.
🔀
Accept Both Changes — keeps both blocks one after another; you may need to tidy the result by hand.
🔍
Compare Changes — opens a side-by-side diff so you can see exactly what's different before choosing.

VS Code shows these four buttons right above every marker block it detects — click one, then save → git add → git commit, same as the terminal method.

Concept · the emergency exit, and avoiding the trip

Abort & prevent

terminal
$ git merge --abort
>> # backs the repo out of the merge completely
>> # your files return to exactly how they were before "git merge" ran

Too messy to resolve right now? Abort, breathe, and try again later — nothing is lost.

Prevention practiceWhy it helps
Pull before you start workYour base is already up to date
Keep branches small & short-livedLess code overlapping with everyone else's
Communicate with your teamTwo people rarely touch the same lines if they talk first
Push oftenSmall diffs are easy for everyone to merge
Merge main into your branch oftenConflicts show up early, in small batches
Use Pull Requests with reviewA second pair of eyes catches risky overlaps before merge
🔌 Simulation · run it in your own terminal

Resolve a conflict

terminal
$ git status
>> Unmerged paths:
>>   both modified:   style.css

$ # Edit style.css: delete the markers, choose a new value
$ echo 'nav background: #1D4ED8;' > style.css

$ git add style.css
$ git status
>> All conflicts fixed but you are still merging.

$ git commit
>> [main e7f8a9b] Merge branch 'feature/green'

Every conflict resolves the same way: find the markers, choose the code, stage it, commit. Run this yourself before the test.

Reference · the condensed command index

Git cheat sheet

Setup & Init

CommandDoes
git config --globalset name/email
git initstart tracking
git clone <url>copy a remote repo

Daily Workflow

CommandDoes
git statuswhat's changed
git add .stage changes
git commit -msave a snapshot
git push / pullsync with GitHub

History

CommandDoes
git log --onelinecompact history
git diffunstaged changes
git restore <file>discard edits

Branching

CommandDoes
git branchlist branches
git checkout -b namecreate + switch
git merge namebring a branch in
git branch -d namedelete a merged branch

Remote & GitHub

CommandDoes
git remote add origin <url>link a remote
git push -u origin mainfirst push, sets tracking
git merge --abortbail out of a conflict
Your turn

Practice challenges

  1. Initialize a brand-new repo and make your first commit.
  2. Create a branch, commit on it, merge it back into main, then delete the branch.
  3. Add a GitHub remote to a local repo and push it.
  4. Deliberately create a merge conflict and resolve it in VS Code.
  5. Write a professional README.md for one of your own projects.
Course complete

You're Ready

You can init a repo, stage & commit, branch & merge, push & pull to GitHub, and resolve conflicts — the everyday workflow of every professional developer.

init → add → commit → branch → merge → push → pull → conflict resolved

Take the final test → ask your instructor for the link.

BrainBit Infotech Teaching, a unit of BrainBit Infotech Private Limited · Ranchi

All slides — click to jump (press O or Esc to close)

BrainBit Infotech Teaching· Git & GitHub
→ / Space · next
←  ·  back  ·  F  ·  fullscreen