The Group Project Nightmare
Riya, Arjun, and Priya are building a Python quiz game for their Class 8 Software Engineering project. They start well: Riya writes the questions, saves the file as quiz.py, and emails it to the other two. Arjun adds a scoring system and emails back quiz_arjun.py. Priya, working from an older email, adds a timer and sends quiz_priya_final.py. By submission night there are five files named things like quiz_FINAL.py, quiz_FINAL2.py, and quiz_FINAL_USE_THIS_ONE.py scattered across three phones and a laptop. Nobody is sure whose scoring code is newest, Arjun's feature has vanished from Priya's copy, and there is no way to tell what changed between any two versions without opening both files and reading every line.
This is not a Riya-and-Arjun problem. It is the default outcome any time more than one person edits the same code without a system for tracking changes. Professional software teams hit this exact wall on day one of every project — dozens of programmers editing the same files, at the same time, from different cities. The tool that solves it is called version control, and the specific tool almost the entire software industry uses is called Git. GitHub is the website built on top of Git that lets teams like Riya's actually work together on it. This chapter builds both, from the ground up, using their quiz game as the running example.
What Version Control Actually Does
Strip away the jargon and version control does exactly three things that "emailing files around" cannot:
- It keeps a complete history of every saved change to a project — not just the latest file, but every version that ever existed, with a timestamp and the name of who made it.
- It lets several people edit the same project at the same time without directly overwriting each other's work.
- It gives the team a precise, line-by-line answer to "what exactly changed, and why?" for any two versions.
Notice what is missing from that list: it does not say "stores files in the cloud." That is GitHub's job, not version control's core job. Git itself works perfectly on a single laptop with no internet connection at all — it tracks history inside a hidden folder on your machine. GitHub then adds a shared, internet-accessible copy of that history so a team can combine their work. Keeping these two ideas separate is the single most important distinction in this chapter, so we will make it explicit before going further.
Git vs. GitHub: A Common Mix-Up, Corrected
Misconception to watch for: many students assume "Git" and "GitHub" are just two names for the same website. They are not, and confusing them causes real mistakes later (like assuming your work is automatically backed up online the moment you save it).
- Git is a program installed on your computer. It watches a project folder and lets you record snapshots of it over time. It needs no internet connection at all.
- GitHub is a website (one of several — GitLab and Bitbucket are similar services) that stores a copy of your Git history online, so that other people can download it, add their own changes, and send those changes back.
A useful comparison: Git is like the "Track Changes" engine inside a word processor — it works locally, on your document, whether or not you are connected to the internet. GitHub is like uploading that document to a shared drive so your group members can open it, edit it, and merge their edits back in. You could use Git your entire life and never touch GitHub. But real teamwork on shared code needs both: Git to record changes, GitHub to share them.
Recording Snapshots: Commits
The core unit of Git's history is called a commit — a saved snapshot of the entire project at one moment, along with a short message describing what changed. Unlike hitting "Save" in a word processor (which overwrites the previous version), a commit never erases what came before; it adds a new snapshot to the timeline, and every earlier snapshot stays retrievable forever.
Here is Riya starting the project on her own laptop, before anyone else is involved:
$ git init
Initialized empty Git repository in /home/riya/quiz-game/.git/
$ git add quiz.py
$ git commit -m "Initial quiz with 5 questions"
[main (root-commit) 0dc5a91] Initial quiz with 5 questions
1 file changed, 12 insertions(+)
Line by line: git init turns the ordinary folder quiz-game into a Git repository — a project Git is now tracking — by creating a hidden .git subfolder that stores all future history. git add quiz.py tells Git "include this file's current state in the next snapshot" (this step is called staging). git commit -m "..." actually takes the snapshot and permanently attaches the message in quotes to it. Git prints back 0dc5a91 — a short version of the commit's unique ID, a long code Git calculates from the file contents and history so that no two commits, anywhere, ever share an ID by accident.
After two more days of work, Riya can see the whole history with one command:
$ git log --oneline
a3f9c2e (HEAD -> main) Add score display to quiz
7b21e4d Fix typo in question 3
0dc5a91 Initial quiz with 5 questions
Read this like a timeline running backward from "now": the newest commit, a3f9c2e, is listed first. HEAD -> main next to it means two things at once — main is the name of the current line of development (Git calls a line of development a branch, covered next), and HEAD is a special marker that always points to whichever commit you currently have open, like a bookmark that says "you are here." Below it, 7b21e4d and 0dc5a91 are the two earlier snapshots, still fully intact and restorable at any time with git checkout 0dc5a91 if Riya ever needed to see the project exactly as it looked before the typo fix.
Branches: Working in Parallel Without Breaking Anything
Once Arjun and Priya join in, a new problem appears: if both of them edit the same shared copy of quiz.py directly, an unfinished, half-working feature from one person could break the game for the other while they're both still mid-edit. Git's answer is the branch — a separate, parallel line of development that starts as an exact copy of the project at one commit, and can be edited freely without touching the original line until the two are deliberately brought back together.
Think of a branch as a photocopy of the group project taken at one exact moment. Priya can scribble all over her photocopy — half-finished, possibly wrong — while Arjun's original stays untouched. When Priya's idea works, the two versions are combined (merged); if it doesn't work, her photocopy can simply be thrown away with zero damage to the original.
Priya creates and switches to a new branch to build a countdown timer, branching off from the point where Riya's score display was added:
$ git checkout -b feature/quiz-timer
Switched to a new branch 'feature/quiz-timer'
git checkout -b is shorthand for two actions in one command: create a new branch named feature/quiz-timer, and immediately switch HEAD to point at it. From here, every commit Priya makes attaches to this new branch only — the shared main branch does not see her changes yet.
The diagram below shows exactly what the project's history looks like once Priya has made two commits on her branch, while main has stayed still, and then what happens when her work is merged back in.
Read the diagram as a timeline flowing left to right. The grey line is main, moving steadily forward with Riya's two commits. At the second blue commit, Priya's green branch splits off and grows on its own — two independent commits that main knows nothing about yet. The orange circle is the merge commit: a special commit whose job is to combine the branch's changes into main. After it, main continues forward as a single line again, now containing everyone's work.
Sharing Work Through GitHub: Push and Pull
Everything so far happened only on Priya's laptop. To let Riya and Arjun see her timer feature, the team needs a shared copy — this is where GitHub enters. Riya creates an empty repository on GitHub named quiz-game and connects her local project to it:
$ git remote add origin https://github.com/riya-cs/quiz-game.git
$ git push origin main
Enumerating objects: 9, done.
Writing objects: 100% (9/9), done.
To https://github.com/riya-cs/quiz-game.git
* [new branch] main -> main
git remote add origin ... gives GitHub's copy of the repository a nickname, origin, so future commands don't need the full web address. git push origin main uploads every commit on the local main branch to that GitHub repository. This is the step that actually puts the code online — notice it is a separate, deliberate action from git commit. This is worth stating as its own rule because it trips up almost every beginner: committing saves a snapshot on your own computer; pushing is the separate step that sends it to GitHub. A commit you never push exists only on your laptop, invisible to your teammates.
Arjun, working on his own laptop, gets a full copy of the project with git clone, and later pulls down anything new that Riya or Priya add with git pull:
$ git clone https://github.com/riya-cs/quiz-game.git
$ git pull origin main
clone is a one-time download of the entire repository, history included — Arjun now has his own local copy, complete with every past commit, ready to branch from. pull is the reverse of push: it downloads any commits from GitHub that Arjun's local copy is missing and adds them to his own history.
Pull Requests: Proposing a Change for Review
Priya could, in principle, push her feature/quiz-timer branch straight into main herself. Professional teams (and good student teams) almost never do this directly, because it skips a valuable step: having someone else look at the change before it becomes part of the shared project. GitHub's tool for this is the pull request, usually abbreviated PR.
A pull request is a formal proposal: "here is my branch, here is exactly what it changes line by line compared to main, please review it and merge it if it looks good." On GitHub, opening a pull request creates a page showing every added and removed line, where Riya and Arjun can leave comments on specific lines, request changes, or approve it. Only after approval does someone click "merge," which performs the same kind of merge commit shown in the diagram above — except now it happens on GitHub's shared copy, and everyone's next git pull receives it.
This review step is what separates "collaborative coding with GitHub" from simply "coding with Git." Git alone tracks history for one person or a team pushing directly into the same branch. GitHub's pull requests add the missing piece — a checkpoint where a second pair of eyes catches bugs, suggests better approaches, or simply confirms the change does what it claims, before it reaches everyone else's copy of the project.
Merge Conflicts: When Two People Edit the Same Line
Branching solves most collision problems, but not all of them. If Priya and Arjun both edit the exact same line of quiz.py on their separate branches, Git cannot guess which version to keep — it stops and asks a human to decide. This is called a merge conflict, and it is not an error or a sign that something broke; it is Git correctly refusing to silently delete someone's work.
Suppose Priya's branch sets a time limit like this:
TIME_LIMIT = 30 # seconds per question
while, on his own separate branch at the same time, Arjun independently changed the same line to:
TIME_LIMIT = 45 # seconds per question, per Arjun's testing
When someone tries to merge both branches into main, Git opens the file and inserts conflict markers around the disputed line, showing both versions side by side:
<<<<<<< HEAD
TIME_LIMIT = 30 # seconds per question
=======
TIME_LIMIT = 45 # seconds per question, per Arjun's testing
>>>>>>> feature/quiz-timer-arjun
Reading this precisely: everything between <<<<<<< HEAD and the ======= divider is the version currently on the branch being merged into (remember, HEAD is the "you are here" bookmark) — here, Priya's 30. Everything between ======= and >>>>>>> feature/quiz-timer-arjun is the incoming version from Arjun's branch — his 45. Git does not choose for them; a team member must open the file, delete the markers, decide on one value (or a new value combining both ideas, like testing to find a better number), save the file, and commit the result:
TIME_LIMIT = 40 # seconds per question, agreed after comparing both tests
$ git add quiz.py
$ git commit -m "Resolve time limit conflict: settle on 40 seconds"
Conflicts only happen on lines both people actually touched. If Priya changed line 12 and Arjun changed line 47 of the same file, Git merges both automatically with no conflict at all — it only asks for help exactly where two people's edits genuinely overlap.
Tracing a Full Run of the Quiz
To ground all of this in working code rather than only commands, here is the merged quiz.py after the team's collaboration, and a trace of what it prints for one sample run:
questions = ["What is 7 x 8?", "What is the capital of India?"]
score = 0
for q in questions:
print(q)
answer = input("Your answer: ")
if answer:
score += 1
print(f"You scored {score} out of {len(questions)}")
Tracing it with sample answers "56" and "New Delhi": the loop starts with score = 0. First pass, q is "What is 7 x 8?"; it prints, the player types "56", which is a non-empty string, so score becomes 1. Second pass, q is "What is the capital of India?"; it prints, the player types "New Delhi", again non-empty, so score becomes 2. The loop ends after two questions, and the final line prints You scored 2 out of 2. Every one of those two commits — Riya's original questions, and the scoring logic that checks for a non-empty answer — is preserved as its own entry in git log, which is precisely why the team can tell, months later, exactly which commit introduced the scoring rule and who wrote it.
The Full Workflow, End to End
Putting every piece together, a realistic collaborative session looks like this: Priya runs git pull to get the latest shared code, creates a branch with git checkout -b feature/quiz-timer, edits and commits her work locally with git add and git commit, then runs git push origin feature/quiz-timer to upload just that branch to GitHub. On GitHub, she opens a pull request comparing her branch to main. Riya reviews the changed lines, leaves a comment, Priya fixes it and pushes an update to the same branch (the pull request updates automatically), and once approved, the pull request is merged — creating the merge commit. If Arjun's branch touched the same line, Git flags the conflict at merge time, someone resolves it by hand, and the resolution itself becomes a commit. Finally, everyone runs git pull again to bring the finished, combined project down to their own laptop.
Check Your Understanding
- Explain, in your own words, why "Git and GitHub are the same thing" is incorrect. What can Git do without any internet connection at all?
- A classmate says, "I already committed my change, so it must be on GitHub now." What is wrong with that statement, and which command did they forget?
- Given the commit history
a3f9c2e (HEAD -> main) Add score display,7b21e4d Fix typo,0dc5a91 Initial quiz, which commit was made first, and how can you tell from the output? - Two teammates edit different functions in the same file on separate branches. Will merging their branches cause a conflict? Explain why or why not, using what you know about how Git decides when to ask for human help.
- Rewrite this conflict block by choosing Arjun's version and removing all conflict markers:
<<<<<<< HEAD/MAX_SCORE = 5/=======/MAX_SCORE = 10/>>>>>>> feature/more-questions. - Why do professional teams usually require a pull request and review before merging into
main, instead of letting anyone push directly?
Summary
Version control exists to solve the exact problem Riya, Arjun, and Priya hit when emailing files back and forth: without it, teams cannot safely track who changed what, or combine simultaneous edits. Git is the local tool that records history as a sequence of commits, each an unerasable snapshot identified by a unique short code. GitHub is the separate, online service that hosts a shared copy of that history, reachable through push and pull. Branches let people work on independent, parallel copies of a project without disturbing each other, until a merge — reviewed on GitHub through a pull request — brings the work back together into one line of history. When two people edit the exact same line, Git raises a merge conflict rather than guessing, marking both versions clearly so a person can choose how to combine them. Mastering this workflow — commit, branch, push, pull request, review, merge, and occasionally resolve a conflict — is what turns "several people editing files" into genuine collaborative software engineering.
Think About It
Think about this: How would you explain collaborative coding with github to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.
Practice Exercises
Now it is time to practice! Complete these challenges to solidify your understanding:
- Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
- Exercise 2: Find a real-world example where collaborative coding with github is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
- Exercise 3: Create a mind-map connecting collaborative coding with github to at least 3 other topics you have studied.