Chapter 5 of 8 · 6 checks · 4 min

Git workflow for a team

A shared repository with a simple branch and pull request workflow prevents lost work, makes review normal and records who built what.

Show

Create one shared repository on day one and give every member accessMust
Why it matters and how to check
Create a single repository for the project, private if your department or partner requires it, and add every member and, if they want, your supervisor. All code, diagram sources and, if you write in LaTeX or Markdown, the report live there.
Nobody keeps working code only on their laptop or shares code through chat files. Check it is done: every member has pushed at least one commit to the shared repository in the first two weeks.
Do
Add every member and optionally the supervisor
Keep diagram sources in the repository too
Avoid
Sharing code as zip files or chat attachments
Work on short-lived branches and merge through pull requestsMust
Why it matters and how to check
A simple workflow suits most student teams: the main branch always runs; each task gets its own branch, such as feature/offline-sync; when it works, open a pull request, a teammate reviews it, then it is merged. The Pro Git book describes this topic branch pattern, and GitHub's documentation describes pull requests as the place to discuss and review changes before merging.
Keep branches small and merge often, so conflicts stay small. Check it is done: recent changes on main arrived through pull requests with at least one teammate's review.
Do
One branch per task, merged through a reviewed pull request
Merge small changes often
Avoid
Everyone pushing directly to main
Branches that live for weeks
Protect the main branch so it cannot be broken by accidentShould
Why it matters and how to check
GitHub lets you set branch protection rules, such as requiring a pull request and an approving review before merging into main. GitHub's documentation lists which plans support this for public and private repositories, so check yours.
Protection turns the team agreement into a rule the tool enforces. Check it is done: a direct push to main is rejected, and merging needs a pull request.
Do
Require a pull request and a review to merge into main
Check which protection features your plan supports
Avoid
Force-pushing over shared history
Commit under your own linked identity with clear messagesMust
Why it matters and how to check
Each member should commit from their own account, with git config user.email set to an email linked to their GitHub account. GitHub's contributors graph only links commits to you when the commit email is connected to your account, and it only counts commits on the default branch; merge commits are not counted.
Write messages that say what changed and why, such as Add conflict resolution for offline batch edits. Do not commit under a teammate's account or squash everyone's work into one person's commits. Check it is done: the contributors page shows every member, and recent messages are descriptive.
Do
Set your commit email to one linked to your account
Write descriptive commit messages
Avoid
Committing from a teammate's machine or account
Messages like update or fix
Keep passwords, API keys and personal data out of the repositoryMust
Why it matters and how to check
API keys, database passwords and real user data pushed to a repository are hard to remove from history and can be misused, especially if the repository is public or later shared.
Use environment variables and a .env file listed in .gitignore, with a .env.example showing the variable names. Keep real datasets with personal information out of Git. Check it is done: searching the repository for key prefixes and passwords finds nothing, and .env is ignored.
Do
Add .env to .gitignore and commit a .env.example
Rotate any key that was ever committed
Avoid
Committing real user data or credentials
Keep a README that lets anyone run the project from scratchShould
Why it matters and how to check
Examiners, supervisors and new teammates all need to run the project. A README should say what the project is, the prerequisites, how to install, configure and run it, how to run tests and where the main code lives.
Test it by having a member clone the repository on a clean machine and follow only the README. Check it is done: someone who did not write the setup can run the project from the README alone.
Do
Include install, configure, run and test steps
Test the README on a clean machine
Avoid
Setup steps that exist only in one member's head