Skip to content

Intermediate · Async JavaScript, modules and tools · topic 44 of 64 · 40 min

Git and GitHub

Explanation

Git saves snapshots (commits) of your project, so you can see what changed, go back, and work on new ideas in branches without breaking the main code. GitHub keeps a copy online, so you can share it, work with a team through pull requests, and show your work to employers.

Why version control?

Without it, projects end up as folders named site-final, site-final-2 and site-REAL-final. Version control is a tool that records every saved change: who changed what, when and why. Git is the version control system almost every company uses. GitHub is a website that hosts Git projects online.

Think of it like this: Think of a shop's account book (bahi khata). Every entry has a date and a note, and old entries are never torn out. If a number looks wrong today, you can turn back the pages and see exactly when it changed. Each Git commit is one dated entry in your project's account book.

Set up once, then the daily loop

bash
git --version                                  # check Git is installed
git config --global user.name "Asha Rao"
git config --global user.email "asha@example.com"
git config --global init.defaultBranch main
Your name and email are written into every commit you make
bash
cd kirana-shop
git init                       # start tracking this folder (creates .git)
git status                     # what changed? what is staged?
git add index.html css/        # stage chosen files
git add .                      # or stage everything
git commit -m "Add product list page"
git log --oneline              # short history: one commit per line
git diff                       # changes not staged yet
The daily loop: change, status, add, commit
AreaWhat it isMoved there by
Working folderYour files as you edit themSaving in the editor
Staging areaChanges chosen for the next commitgit add
Repository (history)Saved snapshots with messagesgit commit

Good commit messages and .gitignore

  • Small commits: one idea per commit.
  • First line (the subject): a short summary in the imperative, like a command, such as "Add cart total" or "Fix PIN code check". Keep it under about 72 characters, with no full stop at the end.
  • If you need more, leave one blank line, then explain why in a body.
  • Bad: "changes", "update", "final fix 2".
output
# .gitignore
node_modules/
dist/
.env
.env.local
.DS_Store
Rebuilt folders and secret files stay out of Git
Careful: Never commit passwords or API keys. Keep them in a .env file listed in .gitignore. If a secret is ever pushed, deleting it in a new commit is not enough, because old commits still have it: revoke the key and make a new one.

Branches, GitHub and pull requests

A branch is a separate line of work. main holds the working code. For each new feature you make a branch, commit there, and merge it into main when it is ready.

bash
git switch -c feature/dark-mode   # create a branch and move to it
# ...edit, add, commit...
git switch main                   # back to main
git merge feature/dark-mode       # bring the feature into main
git branch -d feature/dark-mode   # delete the finished branch
One branch per feature keeps main safe
bash
# after creating an empty repository on GitHub:
git remote add origin https://github.com/asha/kirana-shop.git
git push -u origin main        # send your commits (the first time)
git push                       # later pushes
git pull                       # get your teammates' new commits
git clone https://github.com/asha/kirana-shop.git  # copy a project to a new computer
origin is the usual name for the GitHub copy

In a team, you do not push straight to main. You push your branch and open a pull request (PR) on GitHub: a request to merge it into main. Teammates read the changes, comment on lines, and approve. Automatic checks (tests, linting) can run on every PR. When all is good, the PR is merged.

Resolving a merge conflict

output
<<<<<<< HEAD
<h1>Sharma Kirana Store</h1>
=======
<h1>Sharma General Store</h1>
>>>>>>> feature/new-name
Two branches changed the same line, so Git marks both versions. Above ======= is your current branch; below it is the branch being merged
  1. Open the file and decide what the final code should be (one side, the other, or a mix).
  2. Delete the <<<<<<<, ======= and >>>>>>> marker lines.
  3. Save, then git add the file.
  4. git commit to finish the merge, and test that the page still works.
Tip: Add a README.md to every project: what it is, a screenshot, how to run it (npm install, npm run dev) and a live link. Recruiters often read only your README, so make it clear.

Watch the lesson

Git and GitHub · 1/7

Git = history GitHub = online home

Git records every saved version of your project. GitHub keeps a copy online.

Prefer a video by a teacher? Find free videos on “git and github tutorial for beginners branches pull requests” on YouTube ↗

In real life: A fresher's portfolio on GitHub

A final-year student keeps every practice project on GitHub. Each project has small commits with clear messages, a .gitignore that hides node_modules and .env, and a README with screenshots and a live link. When she applies for a front-end internship, the interviewer opens her GitHub, sees steady work over months, and asks about a pull request where a friend reviewed her code. Her commit history is proof that she really built it.

Practice (0/3 done)

Task 1 · Practice

Install Git (git-scm.com), set your name and email, and turn one of your earlier projects into a repository. Add a .gitignore, then make at least three small commits with clear messages (for example: add the page, add the styles, fix a bug). Look at your history with git log --oneline and at an unstaged change with git diff.

Task 2 · Code · Javascript

Write commitProblems(message) that checks a commit message and returns a list of problems, in this order: "too-long" if the first line (the subject, trimmed) is longer than 72 characters; "ends-with-period" if the subject ends with "."; "no-blank-line" if there is a second line and it is not empty. If the subject is empty, return just ["empty"]. A good message returns []. Example: "Fix login bug\nThe OTP box was hidden" gives ["no-blank-line"].

Task 3 · Practice

Put your project on GitHub and practise the team flow. Create a repository on GitHub, add it as origin and push main. Then make a branch, change the page heading, push the branch and open a pull request; review your own changes on the Files changed tab and merge it. Finally, cause a merge conflict on purpose: change the same heading differently on main and on a new branch, merge, and resolve it by hand.

Quick quiz

Question 1

1.What does git add index.html do?

Question 2

2.Which lines belong in .gitignore for a Vite project?

Question 3

3.What does git switch -c feature/cart do?

Question 4

4.Which commit message is best?

Question 5

5.What is a pull request?

Read more (free)

Pass the quiz (60% or more) or mark this topic as done when you are ready.

Your progress is saved on this device only.

Next: Debugging like a pro: DevTools and VS Code →

← Previous: Modules, npm and Vite