Collaborative Workflow

To work with several people on a repository, there are two main collaboration models. The choice depends mainly on who is allowed to write in the repository.

In a company, you almost always use the shared branch (seen in lessons 01–03). To contribute to an open-source project you are not a member of, you go through the fork.

A fork is a personal copy of a repository on your GitHub account. You have every right there, without touching the original. The clone, on the other hand, downloads a repository onto your local machine.

Do not confuse:

# 1. Forking is done via the "Fork" button on GitHub (or the CLI)
gh repo fork projet/app --clone

# Manual equivalent after a fork:
# 2. Clone YOUR fork
git clone https://github.com/vous/app.git
cd app

# 3. Check the remote
git remote -v
# origin  https://github.com/vous/app.git (fetch/push)

The fork is your “sandbox”: you can break everything without risk for the original project. When your work is ready, a pull request proposes it to the maintainer, who decides whether to accept it.

🔧 Mini-exercise — With gh, fork the repository projet/app and clone it onto your machine in a single command.

While you work, the original repository evolves. Your fork does not update itself. You must add an upstream remote pointing to the original, then fetch its changes regularly.

# 1. Declare the original repository as 'upstream'
git remote add upstream https://github.com/projet/app.git

# 2. Fetch its latest changes
git fetch upstream

# 3. Update your local main
git switch main
git merge upstream/main

# 4. Push into your own fork
git push origin main

Syncing early and often with upstream prevents your fork from “drifting” away from the project. The longer you wait, the more conflicts there will be on the day of the PR.

🔧 Mini-exercise — Write the command to declare the original repository https://github.com/projet/app.git as the upstream remote.

An issue is a ticket: a place to report a bug, propose a feature, or ask a question. It is the tracking system of a GitHub project.

What you put in a good bug issue:

# Create an issue from the terminal
gh issue create --title "Crash on click on Export" \
  --body "Steps: 1) open X 2) click Export → the app closes."

# List open issues
gh issue list

# Link a PR to an issue: in the PR description
#   Closes #42   → automatically closes issue #42 on merge

Labels organize issues: bug, enhancement, documentation, good first issue, help wanted…

Issues turn “we should fix that someday” into traceable and discussable tasks. Linking a PR with Closes #N closes the issue automatically on merge: zero forgotten tickets.

🔧 Mini-exercise — With gh, create an issue titled “Crash on click on Export”.

Beyond the commands, collaborating effectively rests on shared conventions. Here are the ones that make the difference.

The “Conventional Commits” standard, very widespread:

git commit -m "feat: add CSV export"
git commit -m "fix: fix the crash on login"
git commit -m "docs: update the README"
git commit -m "refactor: simplify the payment service"

A team that shares conventions does not need to concert constantly: the code, the commits, and the branches “speak” the same language. That is collaborative fluidity.

🔧 Mini-exercise — You just added CSV export. Write the commit message in Conventional Commits format.

Question 1: What is a fork?

a) A merge of two branches

b) A personal copy of a repository on your GitHub account

c) A type of conflict

d) A deletion of the history

Question 2: What is the difference between origin and upstream in the fork & pull model?

a) None, they are synonyms

b) origin is your fork, upstream is the original repository

c) origin is local, upstream is on your disk

d) upstream is used to delete branches

Question 3: What is an issue for?

a) Compiling the code

b) Reporting a bug, proposing a feature, or discussing a task

c) Automatically merging branches

d) Cloning a repository

Question 4: What does Closes #42 do in a pull request description?

a) Deletes commit 42

b) Automatically closes issue #42 when the PR is merged

c) Opens a new issue

d) Cancels the PR

Question 5: What does the commit prefix fix: mean in Conventional Commits?

a) A new feature

b) A bug fix

c) Documentation

d) A test

Instructions

You want to contribute to an open-source project projet/app of which you are not a member. Complete the full cycle of the fork & pull model:

1. Fork and clone the repository.
2. Add the upstream remote and synchronize your main.
3. Create a branch, make a commit (fixing issue #8) and push it to your fork.
4. Open a pull request toward the original repository while linking the issue.

Correction

# 1. Fork + clone
gh repo fork projet/app --clone
cd app

# 2. Add upstream and synchronize
git remote add upstream https://github.com/projet/app.git
git fetch upstream
git switch main
git merge upstream/main
git push origin main

# 3. Branch, commit, push
git switch -c fix/correction-typo-readme
# ... README file correction ...
git commit -am "fix: fix a typo in the README"
git push -u origin fix/correction-typo-readme

# 4. Open the PR toward the ORIGINAL repository
gh pr create --repo projet/app \
  --base main --head vous:fix/correction-typo-readme \
  --title "fix: typo in the README" \
  --body "Fixes a typo. Closes #8"

Expected result:

$ git remote -v
origin    https://github.com/vous/app.git (push)
upstream  https://github.com/projet/app.git (fetch)

The PR goes from your branch (vous:fix/...) toward the main of the original repository. The maintainer reviews it and decides whether to merge: you just contributed to open source without ever having write access on the project.

Key takeaways

1. Two models: shared branch (internal team) and fork & pull (open source).
2. Fork = copy on your account; clone = copy on your machine.
3. origin = your fork; upstream = the original repository to sync regularly.
4. Issues track bugs, ideas, and tasks; Closes #N links and closes on merge.
5. Good practices: clear commits, short branches, small PRs, stable main.
6. Conventional Commits (feat:, fix:, docs:…) standardize the messages.

What's next

This module 02 is finished: you now know how to branch, merge, open pull requests, and collaborate at scale. Module 03 continues the DevOps path with continuous integration (CI/CD), which will automate tests and deployments from these same pull requests.