🧰 The collaboration toolkit: issues, forks, README

A relaxed tour of the helpful features that live around your code on GitHub, and when to use each one.

1Issues: the repo's built-in to-do list

🧰 A repo on GitHub is a workshop. The code is the workbench. Issues are the job board on the wall. The README is the sign on the door. And .gitignore is the "do not pack" list taped to the moving boxes. This lesson walks you around the room.

Nearly every repo on GitHub has a tab called Issues. (Owners can switch it off, and your own forks start with it off, but you will meet it almost everywhere.) It is a shared to-do list that lives right next to the code. Anyone can pin a card to it: a bug ("the login button is broken on phones"), an idea ("dark mode would be lovely"), or just a question ("how do I run this?").

Each card gets its own number, like #42. Underneath it, a discussion thread where people can reply, paste screenshots, and figure things out together. Cards can wear little colored labels too, like bug or good first issue.

🗣 GitHub's word for one card on this to-do list is an "issue." Despite the gloomy name, an issue is not always a problem. It is just a numbered note that says "someone should look at this."

Here is the magic habit. When you open a pull request that fixes issue #42, write the words Fixes #42 in the PR description. The moment the PR merges, GitHub closes the issue for you. The to-do list cleans itself. Teams that do this never have to ask "wait, did anyone handle that bug?"

2Fork or branch? One question decides

When you want to change a project, ask yourself one question: "Am I part of this project's team?"

If yes: you and your teammates share ONE repo. You make a branch, a bookmark in the shared album, take some photos, push, and open a pull request. That is exactly what you practiced in the last two lessons. Nothing new to learn.

If no: say you find a lovely open source project and spot a typo. You cannot stick bookmarks in a stranger's album: you do not have permission to push there. So GitHub offers a different move. With one click it makes you your OWN full copy of the repo, under your account. Photos, sticky notes, the whole history. You branch and commit in your copy, where you cannot possibly break anything. Then you open a pull request FROM your copy BACK to the original: "I made these changes over here, want them?"

🗣 GitHub's word for your own full copy of someone else's repo is a "fork." You press the Fork button, GitHub copies the whole album to your account, and from then on it is yours to play with. One day you will also meet the word "upstream": it is the friendly nickname people give the original repo their fork came from.

Q. A teammate on the same repo wants to add a feature. They should...

Teammates already have permission to push to the shared repo, so a branch (a bookmark in the shared album) plus a pull request is all they need. Forks are for people outside the team who cannot push to the original.

3README.md: the front door

When you visit a repo on GitHub, one file gets star treatment: README.md. GitHub renders it right on the repo's home page, like a welcome sign. A good README answers three questions: What is this project? How do I run it? How can I help?

The .md stands for Markdown: plain text with a few light symbols for formatting. Here is the entire crash course, thirty seconds, that is all it takes:

# My Project                       ← a big heading
This app tracks your reading list.

It is **free** and easy to run.      ← ** makes bold

- step one: install it              ← - makes a bullet
- step two: enjoy

See [our website](https://example.com)  ← a link

```
npm install && npm run dev          ← code in its own box
```

By the way: every lesson in this course is built on the very same idea. Plain text, light formatting. Once you notice Markdown, you will see it everywhere: GitHub, chat apps, note apps, all of it.

4.gitignore: the do-not-photograph list

Some files should never go in the album. A .gitignore is a plain text file at the top of your repo. Each line is a pattern, and any file that matches becomes invisible to git. It never lands in the shopping basket, never gets photographed, never travels to GitHub.

One catch: .gitignore only hides files git is not already tracking. If a file was photographed before you ignored it, git keeps tracking it until you tell it to stop with git rm --cached <file>.

Three kinds of things belong on the list:

What	Examples	Why
Build junk	node_modules/, .next/	thousands of files your tools can rebuild anytime
OS noise	.DS_Store	little files your Mac sprinkles around
Secrets	.env, API keys, passwords	above all else: these must never be photographed

# .gitignore: things git should never photograph
node_modules/
.next/
.DS_Store
.env

⚠️ A password committed even once lives in history forever. Remember lesson 3: old photos cannot be changed. Deleting the password in a new commit only fixes the newest photo. Every older photo still shows it, to anyone who ever gets a copy of the repo. If a key leaks, treat it as stolen: rotate or revoke it first, then worry about cleaning up.

This is not theoretical. Your own real project keeps its database and email keys in a file called .env, and its .gitignore lists .env for exactly this reason. The secrets stay on your machine, never in the album, never on GitHub.

⌨️ Try it yourself

In your playground folder, create a fake secret and watch .gitignore hide it from git.

cd /tmp/git-playground
echo "SECRET_KEY=12345" > .env
git status
# .env shows up as untracked: one careless "git add ." away from the album. Not good.
echo ".env" >> .gitignore
# >> appends to the file (or creates it), so any lines already there survive
git status
# .env has vanished from the list. git now politely pretends it does not exist.
# .gitignore itself appears instead: commit that, it is safe and meant to be shared.

Q. You accidentally committed a password 10 commits ago, and you just deleted it in a new commit. Safe now?

No. The old photo still contains it, forever, for anyone with a copy of the repo. Treat the secret as leaked: rotate or revoke it immediately, THEN clean up the history, and tell the team so nobody is surprised.

5Small things you will see around

Three more buttons you will bump into on every repo page. One line each:

Button	What it really is
⭐ Star	a bookmark plus applause: saves the repo to your list and tells the owner you like it
👁 Watch	a subscription: GitHub notifies you when new issues and pull requests appear
🏷 Releases	named, downloadable snapshots of the project at a proud moment, like v1.0 or v2.0

None of these change any code. They are just the noticeboard, the doorbell, and the trophy shelf of the workshop.

🧠 If you remember one thing: issues are the repo's to-do list, teammates branch while strangers fork, the README is the front door, and .gitignore makes sure secrets are never photographed.