Working With a Team: Issues, Project Files and Keeping Secrets Safe

Repositories are also workplaces

GitHub is more than storage. Teams use it to plan work, discuss it, review it and release it. This lesson covers the tools around the code that make a repository professional.

Issues: tracking work and bugs

An issue is a page for one task, bug, question or idea. Every project, from a student's notebook to a company's product, uses them.

A good issue has:

• A clear title: "Contact form accepts an empty email", not "Bug".
• What happened and what you expected.
• Steps to reproduce, so someone else can see the problem themselves.
• Context: browser, device, screenshots, error messages.

You can organise issues with labels (bug, enhancement, good first issue, documentation), assignees (who is working on it) and milestones (a group of issues for one release). Each issue has a number, such as #12. In a commit message or pull request, Fixes #12 links the work to the issue and closes it when merged, as you saw in the last lesson.

GitHub Projects adds a board of cards in columns (To do, In progress, Done), a simple way to see who is doing what.

The files that make a repository professional

Open any well-run project, and you find the same few files near the top. Adding them takes minutes and makes the repository look cared for.

GitHub helps: when you create a repository, you can tick Add a README, choose a .gitignore template for your language, and pick a licence.

A README a newcomer can use

A great README answers, in order: What is this? Why should I care? How do I run it? How can I help?

# Kitchen Orders

A small web page where customers choose a meal and send an order on WhatsApp.

## Features
- Menu with prices in naira
- One-tap order message

## Run it
1. Download the project
2. Open `index.html` in your browser

## Contributing
Found a bug? Open an issue. Pull requests are welcome.

## Licence
MIT

Who can do what

For a repository on your account, you decide who may change it. Under Settings, then Collaborators, you can invite teammates. For organisations, there are roles: Read (view and comment), Triage, Write (push branches), Maintain and Admin. Give people the least access they need.

You can also protect main with branch protection rules: require a pull request, require approvals, require checks to pass, and block force pushes. This makes it impossible to push untested work straight to main, even by accident.

Keeping secrets out of Git

This is the most important security lesson in this course. A secret committed to Git is a secret you should consider leaked, even in a private repository, even if you delete the file later.

Secrets include passwords, API keys, tokens, database connection strings, private keys and .env files. Why it is so dangerous:

• Git remembers everything. Deleting the file in a new commit leaves it in the history, which anyone with access (or anyone, if public) can read.
• Bots scan GitHub constantly for keys. A leaked cloud key can be found and abused within minutes, and the bill lands on you.

Prevention

1. Never write a secret directly into code. Keep them in a .env file (or environment variables) and ignore it in .gitignore from the very first commit.
2. Share an example file, .env.example, with fake values, so teammates know what to fill in.
3. Check git status and git diff --staged before every commit. Make it a habit.

If a secret was committed: the steps, in order

1. Revoke or rotate the secret immediately. Go to the service (GitHub, your cloud provider, your payment provider) and delete that key or password and create a new one. This is the step that actually protects you. Do it first.
2. Stop tracking the file, so it stops appearing in future commits:

git rm --cached .env          # remove it from Git, but keep the file on your computer
echo ".env" >> .gitignore     # make sure it is ignored from now on
git add .gitignore
git commit -m "Stop tracking .env"

3. Understand that the old key is still in the history. If the repository is public, or others have cloned it, assume the key is known, and rely on step 1. Specialist tools such as git filter-repo can rewrite history to remove a file, but that is advanced, and it never replaces rotating the key.

Try step 2 in the task below.

Keeping your account safe

• Turn on two-factor authentication (you did this in lesson 1).
• Use tokens or SSH keys, never your password, and give tokens the smallest permissions and a short expiry.
• GitHub has secret scanning and Dependabot alerts (warnings about outdated, vulnerable libraries). Turn them on for your repositories, in Settings, then Code security.

Try it

First, fix a classic mistake: a secret file was committed. Stop tracking it safely.

Now write a bug report as a good issue. The goal is that a developer could reproduce the problem without asking you a single question.