Collaboration
Pull Requests, branches, forks, and Issues — the tools that let multiple developers work on the same project without destroying each other's work.
The problem that branching solves
Imagine three people editing the same Excel file simultaneously, all saving their changes over each other. One person's work overwrites the next. The result is chaos.
Now imagine instead that each person is given their own copy of the file to work in. When they're done, a senior partner reviews each copy, decides what to merge into the master version, and combines the changes deliberately. That's exactly how branches and pull requests work in Git.
Branching is the practice of creating a separate line of development so you can work on a feature or fix without affecting the main version of the project. When your work is done and reviewed, it gets merged back in.
The rule on every shared project: never commit directly to main. Always work on a branch.
Branches
The main branch — where the live, production-ready code lives — is called main (older projects may call it master). It's the source of truth.
When you start working on something new — a feature, a bug fix, a page — you create a branch off main. This gives you a separate space to work without touching the stable code.
Good branch names describe what the work is:
feature/contact-formfix/login-redirect-bugupdate/homepage-hero-text
Excel analogy: A branch is like making a copy of your master Excel workbook — AnnualReport_Draft_Rahul.xlsx — making your edits there, then having the senior partner review your version before the changes go into AnnualReport_MASTER.xlsx. The master stays clean until someone deliberately approves the merge.
When you're ready to send your branch to GitHub, run git push -u origin feature/contact-form (replacing the branch name with yours).
Pull Requests
A Pull Request (PR) is a formal request to merge your branch into main. It's the review checkpoint — the moment where someone (a teammate, a lead developer, or you yourself on a solo project) reviews what changed before it goes into the main codebase.
The name "Pull Request" means: "I'm asking you to pull my changes into your branch."
Excel analogy: A PR is like emailing your draft to the senior partner for review before it's included in the final report. The senior partner can read through it, leave comments on specific sections (specific lines of code in a PR), request changes, and then approve it. Only after approval does it go into the master version.
Creating a pull request on GitHub
Push your branch to GitHub
Make sure your branch and its commits are on GitHub:
Go to your repository on GitHub
Open github.com/your-username/your-repo. GitHub detects that you recently pushed a new branch and shows a yellow banner at the top:
"your-username had recent pushes less than a minute ago — Compare & pull request"
Click the green Compare & pull request button.
Alternatively, go to the Pull requests tab in your repository and click New pull request.
Fill in the PR details
GitHub shows a form with:
Base: main ← the branch you want to merge INTO (usually main)
Compare: feature/contact-form ← your branch
Title: Write a clear title. Not "fix stuff" — but something like "Add contact form with name, email, and message fields."
Description: Explain what the PR does, why, and anything the reviewer should know. This becomes part of the project's permanent record.
A good PR description answers:
- What does this change?
- Why was it needed?
- How was it tested?
Create the PR
Click the green Create pull request button. The PR is now open. On a solo project, you can review and merge it yourself. On a team project, assign a reviewer.
Review the changes
On the PR page, click the Files changed tab. You'll see the diff — every file that changed, every line added (green) and removed (red). This is the same view GitLens shows you in VS Code.
Merge the PR
Once satisfied with the review, click the green Merge pull request button, then Confirm merge. Your branch is now merged into main.
Click Delete branch to clean up the merged branch — it's no longer needed.
main. Click Commits to confirm your commits appear in the main history.Fork vs Clone
These two words sound similar but mean different things:
| Fork | Clone | |
|---|---|---|
| What it creates | A copy of someone else's repository on GitHub, under your account | A download of a repository to your local laptop |
| Who owns it | You own the fork on GitHub | No ownership — just a local working copy |
| Used when | Contributing to someone else's open-source project | Working on your own project or a project you're a collaborator on |
| How | Click the "Fork" button on GitHub | git clone https://github.com/... in terminal |
When you'll use forks: If you want to contribute to a public open-source library or tool on GitHub that you don't have write access to, you fork it, make changes on your fork, and then open a pull request from your fork to the original repository.
When you'll use clone: Everyday work on your own repositories or repositories you've been added to as a collaborator.
For the projects in this program, you'll only use clone — not fork.
GitHub Issues
GitHub Issues is a lightweight task tracker built into every repository. It's where you record bugs, feature requests, and tasks.
To create an Issue:
- Go to your repository on GitHub
- Click the Issues tab
- Click the green New issue button
- Write a title and description
- Optionally assign it to someone, add a label (bug, enhancement, question), or link it to a project
Issues can be linked to pull requests. When a PR description includes "Closes #12" (where 12 is an issue number), merging that PR automatically closes the issue.
For solo work, Issues work as a to-do list that's part of the project's history. For team work, they're how you divide up and track who's doing what.
GitHub notification settings
By default, GitHub sends an email for every comment on every PR and Issue you're involved in. On an active project, this can become noise.
To configure notifications:
- Click your profile photo → Settings
- In the left sidebar, click Notifications
- Under "Default notifications email" — choose your primary email
- Under "Participating and @mentions" — keep email on
- Under "Subscriptions" (watching all activity on subscribed repos) — switch from email to web-only, or turn off
The goal: get notified when someone specifically mentions you (@your-username) or when you're assigned to something. Don't get an email for every comment on every issue in every repository you're watching.
The branch workflow on team projects — summary
On EduTrack and any shared project, the workflow is:
-
Pull the latest from
mainbefore starting any new work: -
Create a branch for your task:
-
Do your work, committing regularly:
-
Push your branch to GitHub:
-
Open a pull request on GitHub. Assign Subhash as the reviewer.
-
Address any review comments. Push additional commits to the same branch — they automatically appear in the open PR.
-
Once approved, merge the PR. Delete the branch.
Never commit directly to main on a shared project. If everyone commits directly to main, nobody can review changes before they go live, and conflicts become painful to resolve. The branch + PR workflow is the difference between a chaotic shared Google Doc where everyone types simultaneously and a structured review process. One saves you hours of untangling every week.