Webbo3 Level 2 · JavaScript Development · Day 10 of 20

Git, GitHub and Project 2: Solve a Problem

Five people, one codebase, nobody overwriting anybody. The workflow every team you will ever join already uses.

Until today your repository has had one branch and one person. Today it gets four more people, and every habit that was merely untidy becomes genuinely expensive. Learn this properly now, on a small project, rather than in your first job on a big one.

1. Why branches exist

If five people all commit to main, everybody is editing the same live copy. Somebody pushes broken code and the project is broken for all five. Two people touch the same function and one silently loses their work.

A branch is your own copy of the project to work in. You break things in it freely, and when your piece is finished and works you ask for it to be merged.

main                    always working, always deployable
 |
 +-- development        where finished features are combined and tested
      |
      +-- feature/search        Chidinma
      +-- feature/api-client    Musa
      +-- feature/filters       Amaka
      +-- fix/empty-state       Tunde

2. The commands you will use every day

git status                       # what have I changed? run this constantly
git switch -c feature/search     # make a branch and move onto it
git add .                        # stage everything changed
git commit -m "Add debounced search to the student list"
git push -u origin feature/search   # first push of a new branch

# before you start each day, and before you open a pull request
git switch development
git pull                         # get everybody else's merged work
git switch feature/search
git merge development            # bring it into your branch

3. Commit messages that earn their place

You will read these when something breaks and you are trying to find the commit that caused it. "update" tells you nothing at 11pm.

The rule that gets you there: finish the sentence "If applied, this commit will...". Present tense, says what changed, and never mentions how long it took.

4. Pull requests

A pull request says: here is my branch, here is what it does, please look at it before it goes in. It is where code review happens, and code review is the single most effective way teams catch bugs before users do.

## What this does
Adds a debounced search box to the student list.

## Why
Filtering 200 students by scrolling was unusable on a phone.

## How to test it
1. Open the students page
2. Type "chi" slowly, then quickly
3. Confirm only one search runs, and the empty state shows for "zzzz"

## Notes
Search is local because the whole list is already fetched. If the list grows
past a few hundred, this should move to the API.

Reviewing somebody else's pull request

• Pull the branch and run it. A review that only reads the diff misses anything that does not happen on screen.
• Ask questions rather than issuing orders. "What happens here if items is empty?" lands very differently from "this is wrong".
• Say what is good. A review that is only criticism makes people defensive and slower.
• Check the things this course has taught: is user text going in with textContent, is response.ok checked, is there an empty state, can they explain it.

5. Merge conflicts

A conflict happens when two branches changed the same lines. Git cannot know which one is right, so it stops and asks. It is not an error and you have not broken anything.

<<<<<<< HEAD
const PER_PAGE = 10;
=======
const PER_PAGE = 20;
>>>>>>> feature/filters

1. Above ======= is what is already on your branch. Below it is what is coming in.
2. Edit the file so it reads correctly: keep one, keep the other, or write a third thing that satisfies both.
3. Delete all three marker lines. Leaving a <<<<<<< in the file is a syntax error, and it is the most common way a conflict resolution goes wrong.
4. Then git add the file and git commit.

6. Project 2: the brief

That is the whole brief, and it names a problem rather than a product. What you build is your team's decision and part of what is assessed. Two teams will reasonably build different things from this.

What it must include

• Data from at least one real API, fetched and rendered.
• Search and at least one filter or category.
• All four states from yesterday: loading, error, empty, list.
• Modules, not one file. At minimum an API layer, a render layer and the wiring.
• Works at phone width.
• A README explaining the problem, the solution and how to run it.

7. How the team works

The working rhythm

1. Break the build into GitHub Issues, one per piece of work, each small enough for one person in half a day.
2. Assign each issue to a person. One issue, one branch, one pull request.
3. Nobody pushes to main or development directly. Ever.
4. Every pull request needs one review from somebody else before it merges.
5. Stand up for five minutes each morning: what I did, what I am doing, what is blocking me.

8. The marking rubric

Do this now

1. Create the repository. Add a README and a .gitignore before anything else.
2. Create development off main. Protect both if your plan allows it.
3. Open at least eight issues and assign every one of them.
4. Everybody creates their branch and pushes an empty commit today, so you find out today rather than on Thursday that somebody's Git access does not work.
5. Agree three things in writing in the README: what you are building, what is explicitly out of scope, and who reviews whose pull requests.

Checkpoint

Next week: state, storage, browser APIs, accessibility and debugging. The week that turns a student who can build into a junior developer.