All the reading

Git & GitHub

8 lessons, about 33 minutes. The check's questions come from these.

Inspecting staged and changed files

1. What Git actually tracks

4 min

Key point

The core idea

Git tracks changes to files inside one project folder. A commit is a saved snapshot of selected changes, with a message that explains why you saved it.

Git does not understand your app like a human. It only sees file paths, file contents, and changes between snapshots.

Why this matters

A recruiter may open your GitHub repo before they meet you. Your commits should show steady, understandable work, not one giant upload at 3 am before submission.

To get there, you first need to know what Git notices. It notices when a tracked file changes. It notices new files. It notices deleted files. It ignores files you tell it to ignore.

Your to-do

The three areas

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Work in your folder. These are your normal project files.
Stage the changes you want in the next commit using git add.
Commit the staged changes using git commit, so Git saves a snapshot.

0 of 3 done

Example

See what Git sees

In any Git repo, these commands answer the two most useful questions: what changed, and what exactly changed.

Run them before you commit. This habit prevents broken setup files, secrets, and random test code from entering your public repo.

Setting up repo and ignores

2. Set up your repo safely

4 min

Key point

One safe rule

Start Git at the root of one project, then keep private, generated, and machine-specific files out of commits.

A recruiter should see source code, setup files, and docs. They should not see your .env, node_modules, venv, build output, or personal editor settings.

Choose the root

The repo root is the main folder for your project. It is usually the folder that contains package.json, requirements.txt, pyproject.toml, or your main app folder.

Do not run git init in your Desktop, Downloads, college lab folder, or inside a folder that already has another .git folder.

Your to-do

Check before init

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Writing commits and merging branches

3. Make commits that read well

4 min

Key point

One change each

A good commit is one small, complete change with a clear message. Think of it like an entry in your project diary: what changed, and why it matters.

Recruiters may not read every line of code. But they can scan your commits to see how you built, fixed, and improved the project.

What readable means

Readable commit history does not mean perfect history. It means each commit has a purpose.

Bad history looks like this: final, fix, update, working, changes. Good history shows progress: add login form, validate UPI ID input, fix empty cart total.

Your to-do

Make focused commits

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Undoing mistakes and shipping repo

5. Get out of Git trouble

4 min

Key point

Pause before fixing

Most Git trouble gets worse when you copy random commands. First inspect what changed, what is staged, and where HEAD points.

Your safe order is: git status, git diff, git log --oneline. Then choose the smallest fix.

Your to-do

Check the damage

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Run git status to see changed, staged, and untracked files.
Run git diff to see unstaged edits line by line.
Run git diff --staged to see what will go into the next commit.
Run git log --oneline --decorate -5 to see recent commits and branch labels.
Copy the exact error message if Git prints one. Do not guess.

0 of 5 done

Example

10 questions, 7 to pass.

Example

Files to ignore

A .gitignore file tells Git which files should usually stay out of commits. This is important for public HackIndia projects because strangers should get source code, not your machine clutter.

Here is a simple example for many JavaScript projects.

node_modules/
.env
.DS_Store
dist/
coverage/

Example

Safe first setup

This example is for a Node project. The same idea applies to Python, Java, Flutter, or any stack: ignore installs, secrets, logs, and build output.

cd my-college-project
git init

cat > .gitignore <<'EOF'
# installs
node_modules/

# secrets
.env
.env.local

# logs
*.log

# build output
dist/
build/

# OS and editor files
.DS_Store
.vscode/
EOF

git status

Common mistake

Do not commit secrets

A .env file often has API keys, database URLs, JWT secrets, or payment keys. If it reaches a public GitHub repo, assume it is leaked.

Instead, commit a sample file that shows the names of required variables without real values.

.env.example

MONGODB_URI=
JWT_SECRET=
RAZORPAY_KEY_ID=
RAZORPAY_KEY_SECRET=

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to create a .gitignore for your stack. Give it your tech stack and folder names.

Check the result before using it. It should not ignore real source folders like src, app, pages, components, or backend. It should ignore dependency folders, build output, logs, and local secrets.

Prompt:
Create a .gitignore for a MERN project with React in client and Express in server. We use .env files in both folders. Do not ignore source code.

Your to-do

Make first commit

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Run git status and read the list before adding anything.
Add only safe files with git add, not blindly if you are unsure.
Commit with a simple message like chore: initialise project repo.
Run git status again and confirm the working tree is clean.

0 of 4 done

git status
git add .gitignore README.md package.json package-lock.json src server client
git commit -m "chore: initialise project repo"
git status

Example

Good commit flow

Use this when you changed a form and also edited the README. These are different ideas, so commit them separately.

The first commit changes app behaviour. The second commit improves project instructions.

git status
git diff

git add src/components/LoginForm.jsx src/utils/validateUpi.js
git commit -m "Add UPI ID validation to login form"

git add README.md
git commit -m "Document local setup steps"

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to suggest a commit message from your diff. Paste only code you are allowed to share.

Check that the message is specific, honest, and not too broad. If AI says improve app, rewrite it to say what actually changed.

Prompt:
Suggest 5 short Git commit messages for this diff.
Use imperative mood.
Do not mention files unless needed.

[Paste git diff output]

Common mistake

Do not commit noise

Beginners often commit generated files, local settings, or secrets. That makes the repo harder to review and can leak private data.

Before every commit, scan the file list. If you see .env, API keys, node_modules, build folders, or personal notes, stop and fix your .gitignore.

git status

# If you accidentally staged a file, unstage it:
git restore --staged .env

Example

Message patterns

A useful message starts with a verb. Keep it short, but not vague.

If the why is not obvious, add a longer body. This is useful for bug fixes and tradeoffs.

git commit -m "Fix cart total when quantity is zero"

git commit -m "Replace mock data with API fetch" -m "This keeps the product list in sync with the backend and removes hardcoded demo items."

4. Branch and merge without fear

4 min

Key point

One safe idea

A branch is a separate line of work. Use it when you are adding a feature, fixing a bug, or trying an idea that may break the project.

Keep main as the working version. Do your messy work on a branch, test it, then merge it back.

Why branches help

In a hackathon team, two people may edit the project at the same time. One person works on login. Another updates the landing page. Branches stop both changes from getting mixed too early.

Even when you work solo, branches help your commit history. A recruiter can see one clean story: branch made, commits added, branch merged.

Your to-do

Create a branch

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Check your current status before changing branches.
Create and switch to a branch with a clear name.
Make one type of change on that branch.
Commit your work when it runs.
Switch back to main only after committing or stashing your changes.

0 of 5 done

git status
git switch -c feature/add-expense-form

# edit files, run the project, then commit
git add .
git commit -m "Add expense form"

git switch main

Tip

Name branches clearly

Use names that explain the work. Good names are short and specific.

Try feature/add-login, fix/navbar-mobile, docs/update-setup. Avoid names like final, changes, newbranch, or mywork.

Your to-do

Merge back safely

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Switch to main.
Pull the latest changes if your repo is already on GitHub.
Merge your branch into main.
Run the project and check the changed feature.
Delete the branch only after the merge is good.

0 of 5 done

git switch main
git pull
git merge feature/add-expense-form

# test your app here

git branch -d feature/add-expense-form

Common mistake

Do not panic

A merge conflict does not mean the repo is broken. It means Git found the same part of a file changed in two branches and wants you to choose.

Open the file, remove the conflict markers, keep the correct code, then commit the merge.

Example

Conflict example

You may see a file like this after a merge conflict. The top part is from your current branch. The bottom part is from the branch being merged.

Edit it into the final version you want. Do not leave the marker lines in the file.

<<<<<<< HEAD
const title = "Campus Expense Tracker";
=======
const title = "Student Budget Tracker";
>>>>>>> feature/add-expense-form

# final file could be:
const title = "Student Budget Tracker";

# then finish the merge
git add src/config.js
git commit

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Run git status in your project.
Create a branch named feature/readme-draft or another real change.
Make a small change, such as adding one setup note or one UI text fix.
Commit it with a clear message.
Switch to main and merge the branch after checking the change.

0 of 5 done

git status
git switch -c feature/readme-draft
# make a small edit
git add .
git commit -m "Draft setup note"
git switch main
git merge feature/readme-draft

Example

Unstage wrong files

Maybe you ran git add . and included .env, screenshots, or half-written code. Unstage them. This keeps the file changes on your laptop.

git status
git restore --staged .env
git restore --staged src/rough-notes.js
git status

Common mistake

Reset is not magic

Beginners use git reset --hard because Stack Overflow said so. It deletes tracked local changes in your working tree.

Use it only when you are sure you want to throw away local edits. For a college project repo, first make a backup branch if you are unsure.

git branch backup-before-fix
git status

Example

Fix a bad commit

If the bad commit is only on your laptop, you can move back one commit and keep the file changes. Then recommit properly.

If the commit is already pushed and teammates may have pulled it, prefer git revert. Revert creates a new commit that undoes the old one.

# Local commit, not pushed yet
git reset --soft HEAD~1
git status

# Pushed commit, safer for shared history
git log --oneline
git revert <commit-hash>

Tip

Use reflog rescue

Reflog records where your HEAD and branches recently pointed. It helps when you reset, checkout, or rebase to the wrong place.

Find the commit you want, then create a branch there. A new branch is safer than moving your current branch again.

git reflog
git branch rescue <commit-hash>
git switch rescue

6. Push your project to GitHub

4 min

Key point

One idea

GitHub is not where Git starts. Your local repo already has the commits. GitHub is the remote copy you push to so others can see it.

For this lesson, your goal is simple: connect local to remote, push, and verify the public repo looks right.

Before you push

Finish one clean commit locally before you create the GitHub repo. Do not push a half-added project just because the commands are ready.

Run status first. If you see files you did not mean to share, stop and fix it before GitHub gets a copy.

Example

Check your repo

Use these commands from your project folder. They tell you whether your repo is clean and what branch name you are on.

git status
git branch --show-current
git log --oneline -5

Your to-do

Create GitHub repo

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open GitHub and sign in.
Click New repository.
Use a clear repo name, like mess-menu-app or campus-lost-found.
Choose Public if this is your HackIndia submission repo.
Do not add README, .gitignore, or license on GitHub if your local repo already has files.
Create the repository.

0 of 6 done

Your to-do

Connect and push

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Copy the repo URL from GitHub. HTTPS is fine for most builders.
Add GitHub as your remote named origin.
Rename your branch to main if needed.
Push your commits and set the upstream link.
Refresh GitHub and check that your files appear.

0 of 5 done

git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPO.git
git branch -M main
git push -u origin main

Tip

What upstream means

The -u in git push -u origin main links your local main branch to GitHub's main branch.

After that, you can usually run only git push for new commits, and git pull when you need to bring changes down.

Common mistake

Common push problems

If Git says remote origin already exists, your project is already connected to a remote. Check it before changing anything.

If GitHub asks for login, use your normal GitHub authentication flow. Do not paste passwords into random terminals or share tokens in screenshots.

git remote -v

git remote set-url origin https://github.com/YOUR-USERNAME/YOUR-REPO.git

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Run git status and make sure your working tree is clean.
Create a new public GitHub repo without adding extra files on GitHub.
Connect it with git remote add origin using your repo URL.
Push with git push -u origin main.
Open GitHub and check files, commit history, and public visibility.

0 of 5 done

7. Write a README strangers can run

5 min

Key point

One job

Your README has one job: help a stranger understand and run your project.

Assume the reader is a recruiter, judge, or senior student. They will not DM you for missing steps.

What to include

A good hackathon README is not long. It is complete.

Put the most useful information near the top, because people scan on phones and laptops.

Name the project and the problem it solves.
Show the tech stack, like React, Node.js, Flask, Firebase, or MongoDB.
Explain the main features in 3 to 6 bullets.
Give exact setup commands.
List required environment variables without sharing secrets.
Add screenshots or a short demo link if you have one.

Common mistake

Common README mistake

Beginners write only: “Run npm install and npm start.” That is not enough for a stranger.

Mention the required Node, Python, Java, or database version if your project depends on it. If an API key is needed, say where to add it and what name to use.

Example

README skeleton

Use this structure. Replace the details with your project.

Do not paste fake commands. Only include commands you have tested.

# Campus Mess Feedback

A web app for college students to submit mess food feedback and for admins to view trends.

## Features

- Student feedback form
- Admin dashboard
- Daily rating summary
- Firebase authentication

## Tech stack

- React
- Firebase
- Tailwind CSS

## Screenshots

Add screenshots here.

## Setup

1. Clone the repo

```bash
git clone https://github.com/your-username/campus-mess-feedback.git
cd campus-mess-feedback
```

2. Install dependencies

```bash
npm install
```

3. Create a `.env` file

```bash
VITE_FIREBASE_API_KEY=your_key_here
VITE_FIREBASE_AUTH_DOMAIN=your_auth_domain_here
```

4. Start the app

```bash
npm run dev
```

Open the local URL shown in the terminal.

## Demo login

Student: [email protected] / password123
Admin: [email protected] / password123

## What I learned

- Built protected routes
- Connected Firebase auth
- Designed a simple dashboard for real users

Tip

Use AI carefully

Ask ChatGPT, Gemini, or Claude to draft the README from your code and package files. This saves time, but you must verify it.

Check every command, every env variable name, and every feature claim. AI often adds features you did not build or misses setup steps.

Prompt:

Read this project structure, package.json, and main files. Draft a beginner-friendly README for GitHub. Include project summary, features, tech stack, setup commands, environment variables, and how to run locally. Do not invent features.

Then paste your package.json and folder structure.

Your to-do

Test like a stranger

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Copy your GitHub repo URL.
Clone it into a new folder outside your project folder.
Follow only the README, not your memory.
Fix every missing command, file name, or env variable.
Ask a friend to try the setup if you can.

0 of 5 done

git clone https://github.com/your-username/your-repo.git
cd your-repo

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your repo and create or edit README.md.
Add the project summary, features, tech stack, and setup steps.
Add a .env.example file if your app needs secrets.
Run the project from a fresh clone using only the README.
Commit the README update with a clear message.

0 of 5 done

git add README.md .env.example
git commit -m "Add clear setup instructions to README"

8. Submit your public repo

4 min

Key point

Submission means proof

Your GitHub repo is the proof that your project exists, runs, and was built by your team. Before you submit, check it from a stranger’s view, not from your laptop.

A recruiter or judge should understand what it does, how to run it, and what changed over time without messaging you.

Your to-do

Check the public view

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your repo in an incognito window or a browser where you are not logged in.
Confirm the repo is public, not private.
Check that the README appears on the repo home page.
Open the commits page and scan if the messages are readable.
Click the main files and confirm the latest work is pushed.

0 of 5 done

Common mistake

Do not submit localhost

A common mistake is submitting a local folder path, a Google Drive zip, or a link that only works for your account. HackIndia needs a public GitHub repository link.

Another mistake is pushing code but forgetting environment instructions. If your project needs API keys, say which variables are needed, but never commit the real keys.

Example

Final repo check

Run these commands in your project folder before submission. They help you catch uncommitted work and confirm your code is connected to GitHub.

git status
git log --oneline -5
git remote -v
git branch --show-current

What clean looks like

git status should say your working tree is clean. If it shows modified files, either commit them or remove the changes if they are not needed.

git log should show recent commits with useful messages. git remote -v should show the GitHub URL you plan to submit. Your current branch should be the branch visible on GitHub, usually main.

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to review your README before submission. Paste the README and ask: “Can a first-year student run this project from these instructions? List missing steps only.”

Check every suggestion. AI may assume commands, package managers, ports, or file names that your repo does not use.

Your to-do

Submit on HackIndia

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Copy the GitHub repo URL from the browser address bar, not from your terminal.
Paste it into the HackIndia project submission field.
Add the live demo link only if it works for someone else without your login.
Mention your main tech stack and one clear project outcome in the submission text.
Ask one teammate or friend to open the repo link on mobile data and confirm it loads.

0 of 5 done

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your repo in incognito and confirm it is public.
Run git status and fix any uncommitted work.
Check the README setup steps from a fresh view.
Copy the GitHub repo URL and save it in your notes.
Submit the public repo link on HackIndia when your checks pass.

0 of 5 done

Git & GitHub

1. What Git actually tracks

The core idea

Why this matters

The three areas

See what Git sees

2. Set up your repo safely

One safe rule

Choose the root

Check before init

3. Make commits that read well

One change each

What readable means

Make focused commits

5. Get out of Git trouble

Pause before fixing

Check the damage

Common wrong idea

Use AI carefully

Files to ignore

Do this now

Safe first setup

Do not commit secrets

Use AI carefully

Make first commit

Do this now

Good commit flow

Use AI carefully

Do not commit noise

Message patterns

Do this now

4. Branch and merge without fear

One safe idea

Why branches help

Create a branch

Name branches clearly

Merge back safely

Do not panic

Conflict example

Do this now

Undo file edits

Unstage wrong files

Reset is not magic

Fix a bad commit

Use reflog rescue

Do this now

6. Push your project to GitHub

One idea

Before you push

Check your repo

Create GitHub repo

Connect and push

What upstream means

Common push problems

Do this now

7. Write a README strangers can run

One job

What to include

Common README mistake

README skeleton

Use AI carefully

Test like a stranger

Do this now

8. Submit your public repo

Submission means proof

Check the public view

Do not submit localhost

Final repo check

What clean looks like

Use AI carefully

Submit on HackIndia

Do this now