# Git for group projects: how your team works on one codebase without wiping out each other

> **The short answer**: Learning Git for a group project starts with one rule: nobody writes to the main branch directly. Each member makes a branch for a task, pushes it, and opens a pull request that a teammate reviews before merging. The main branch keeps working, and the team can see who changed what.[^1][^2]
>
> tiswa lists the current student offers in Saudi Arabia for [GitHub](https://tiswa.app/en/deals/github-student-pack/).

**Key takeaways**

- A branch is a lightweight pointer to a snapshot, and creating one is nearly instant.[^1]
- One branch per task; nobody commits to main directly.
- A pull request is a proposal the team discusses and reviews before it enters the project.[^2]
- Resolve conflicts on your branch before merging, never on main.

![Git for group projects: how your team works on one codebase without wiping out each other](https://tiswa.app/assets/blog/git-group-project-branches-review/git-group-project-branches-review-cover-en.webp)

Four students on a graduation coding project. One writes the login page, another edits the same file to fix a bug, a third pushes a copy over the fourth’s work. Two hours later half the project runs and half does not, and nobody knows which change broke what. Git is not the problem; it was built to prevent exactly this. The team is using it as a shared folder instead of a collaboration tool.

> **tiswa's take**: When we explain Git to students we start with rules, not commands. Every team that struggles knows the same five commands. The teams that succeed agree three rules: a branch per task, a review before merging, and a main branch that never breaks. You can learn the commands in the first week.

## How do you learn programming with GitHub as a team?

Start with the core idea, the branch. The Pro Git book describes a branch as a lightweight, movable pointer to a snapshot of the project, and each new commit moves the branch you are on.[^1] That makes creating a branch fast and cheap, so you can make one for every task without hesitation. If you have never made a repository, begin with [GitHub for beginners](https://tiswa.app/en/blog/github-for-beginners/), and for the programming itself see [learning to code from zero](https://tiswa.app/en/blog/learn-programming-from-zero/).

## How do you create a branch and work on it step by step?

1. **Update your copy**: Before any task, pull the latest main: git switch main, then git pull.
2. **Create your branch**: git switch -c login-page. The c option creates the branch and switches to it in one step.[^1] Choose a name that describes the task.
3. **Work and commit**: Edit files, then git add and git commit -m "Add login form". Make the message a sentence that says what changed.
4. **Push the branch**: git push -u origin login-page uploads your branch to the shared repository.
5. **Open a pull request**: On the repository page, open a Pull Request from your branch into main, with two lines: what you changed and how to try it.

![5 steps: How do you create a branch and work on it step by step (Update your copy, Create your branch, Work and commit, …)](https://tiswa.app/assets/blog/git-group-project-branches-review/git-group-project-branches-review-inline-1-en.webp)


These commands are a worked example. The branch names and messages are ours, so swap in whatever suits your project.

## What does a pull request actually do?

GitHub’s documentation defines a pull request as a proposal to merge changes into a project and as its main collaboration feature, because it lets people discuss and review changes before they reach the main codebase.[^2] Each request has tabs: Conversation for the description and comments, Files changed for the diff reviewers read, and a merge status that lists what is blocking the merge.[^2] The documentation also notes that draft pull requests cannot be merged, and that drafts let teammates see progress before you ask for review.[^2]

| Who | What they do | When |
|---|---|---|
| Task owner | Opens the pull request as a draft | When work starts and the team should see it |
| Task owner | Marks it ready for review | After testing it personally |
| Reviewer | Reads Files changed and comments | The same day if possible |
| Task owner | Handles the comments | Before merging |
| Reviewer or team | Merges | When approved and nothing blocks it |

![Table: What does a pull request actually do (Task owner, Task owner, Reviewer, …)](https://tiswa.app/assets/blog/git-group-project-branches-review/git-group-project-branches-review-inline-2-en.webp)


## How do you review a teammate’s work?

A review is not a trial. Read the changed files and answer four questions: does it work, will I understand it in a month, did it change anything outside its task, does it break something I wrote? Comment in specific sentences: “this function repeats in another file” helps more than “unclear.” Note who approved, because some courses ask the team to show how the work was divided, and the pull request history gives you that evidence at no extra cost.

## What do you do when there is a merge conflict?

A conflict happens when two people edit the same line. Do not panic: it means Git declined to guess on your behalf. Merge main into your branch first, open the file, and you will find both versions between conflict markers. Read them with the teammate who made the other change, keep what is right from each, delete the markers, then commit and push. Resolve it on your branch, not on main, so main keeps working.

1. **Bring main into your branch**: git switch login-page, then git merge main.
2. **Open the conflicting file**: Look for the markers <<<<<<<, ======= and >>>>>>> and decide what stays.
3. **Combine and test**: Remove the markers and run the project to be sure it works.
4. **Commit and push**: git add, git commit, git push.

## How do you use GitHub for a graduation project?

A week before the deadline agree a freeze: nothing merges except fixes. Then run the project from a fresh download of the repository, not from one member’s machine, which exposes files you forgot to push. Ask your supervisor whether they want a repository link or a zip file, since that varies by course and we give no general rule. If design files and the written report sit beside the code, see [capstone version control in Drive](https://tiswa.app/en/blog/capstone-drive-version-control/).

To start with a simple language, take [Python](https://tiswa.app/en/blog/learn-python/) and practise this whole route on a small project of three files before you try it on your graduation project.

Whenever you doubt where a project stands, run git status to see which branch you are on and what is not yet committed, then git log --oneline to see the latest commits. Neither command changes anything, so use them freely before every step.

Public repositories are free for learning. For the tools and subscriptions your project needs, browse the [student discounts in Saudi Arabia](https://tiswa.app/en/deals/). [Browse student deals](https://tiswa.app/en/join/)

## Questions

### Learn programming GitHub: where do I start as a student?

Start with a small three-file project and practise five commands: switch, add, commit, push and pull. Then open a pull request for a teammate.

### What is the difference between a branch and a pull request?

A branch is a separate line of work. A pull request is a proposal to merge your branch into another one after discussion and review.[^1][^2]

### How many branches should a team project have?

One per small task. Branches are cheap, and the smaller the task, the easier the review.[^1]

### What should I do when I get a merge conflict?

Merge main into your branch, open the file, decide with your teammate what stays between the markers, then commit and push.

### Can you merge a draft pull request?

No. GitHub’s documentation says drafts cannot be merged until they are marked ready for review.[^2]

### Can I use GitHub as a study app for my graduation project?

GitHub keeps your code and history in one place, but it is not a study app. Whether a repository counts as a hand-in varies by course, so ask your supervisor before the project starts.


## Sources

[^1]: Pro Git: Branches in a Nutshell, https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
[^2]: GitHub Docs: About pull requests, https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests