GitHub: working with a team
Lesson 2 of 3
2GitHub: working with a team
The big pictureGit keeps your history on your machine; GitHub makes it shared: a copy in the cloud and a place where teammates review each other's work before it enters the product.
What the picture shows: This is "GitHub Flow": every change goes through a pull request that is reviewed and tested automatically before it enters the main branch.
Map of this part
The concepts in order, click any one to jump to it:
Two ways into the same idea
Like a shared company document: each employee drafts in their own copy (a branch), then sends it to the manager saying "review before approval" (a pull request). The manager comments, the employee revises, then it is approved into the official copy (main).
origin is the remote's name. git push -u origin feature uploads the branch and sets it to track, and git pull = fetch + merge (or rebase). A pull request compares two branches, runs CI checks, and collects review comments on lines. Branch protection blocks merging without review or with failing checks. A conflict happens when two branches change the same lines, so Git writes <<<<<<<, ======= and >>>>>>> markers for you to decide.
Before You Start
📸Git from zero
You know add, commit and branches.
🌐A GitHub account
Create a free account at github.com.
The Core Idea
1The remote: push and pull
git clone downloads a whole repository. git push uploads your commits, and git pull brings in your teammates'. Always start your day with git pull on main.
git clone https://github.com/you/notes.git cd notes git switch -c fix-typo # ... edit, add, commit ... git push -u origin fix-typo
2Pull requests and review
After pushing, GitHub offers to open a pull request. Write what you changed, why, and how you tested it. A teammate comments on lines; you revise and push a new commit to the same branch, and the request updates by itself.
3Issues
An issue records a task or a bug: a title, a description, steps to reproduce, and who is on it. In a pull request you write Fixes #12 and issue 12 closes by itself on merge.
4Resolving a merge conflict
When two people change the same line, Git stops and writes markers into the file. You decide the final text, remove the markers, then add and commit.
<<<<<<< HEAD Welcome to Darb, your path to engineering. ======= Welcome to Darb, learn to build software. >>>>>>> fix-typo
Worked example
Problem: you pushed your branch and GitHub said "rejected: fetch first". Cause: a teammate pushed commits to the same branch after you. Fix: git pull to fetch and merge them, resolve any conflict, then git push again. Never --force a branch someone shares with you.
Myth vs Reality
| Myth | Reality |
|---|---|
| A pull request means my work is bad and needs fixing. | It is standard in every professional team; even senior engineers get reviewed. Review spreads knowledge and catches bugs. |
| A conflict means someone made a mistake. | It is normal when two people work on the same file. Git just asks you to decide. |
Test your understanding
What does git pull do?
pull = fetch + merge.
You see <<<<<<< HEAD in a file. What happened?
Git put both sides between markers for you to choose the final text.
Which phrase in a pull request closes issue 7 on merge?
Fixes, Closes and Resolves tie closing to the merge.
Quick review cards
Check Your Understanding
What goes in a pull request description?
What you changed, why, how you tested it, and the issue link if any.
Why is --force dangerous on a shared branch?
Because it replaces the remote history with yours, erasing teammates' commits you did not have.
What are the steps to resolve a conflict?
Open the file, read both sides, write the final text, remove the markers, run the program, then add and commit.
Resources for this lesson
Grouped by type. Start with the official docs for precision, or an article or video for the explanation.
Official docs1
Done with this lesson?
Sign in to save your progress.