Git Notes
Software development is a team sport. Even the most brilliant developer cannot build and maintain complex systems alone. Git and GitHub provide the...
Software development is a team sport. Even the most brilliant developer cannot build and maintain complex systems alone. Git and GitHub provide the infrastructure for teams to work simultaneously on the same codebase without chaos. Understanding collaboration patterns, conventions, and tools transforms a group of individual developers into an effective engineering team.
The Foundation: Shared Repository Model
In most professional environments, teams use a shared repository where everyone has push access (within rules). The basic collaboration model:
- Everyone clones the same repository
- Developers create feature branches for their work
- Work is reviewed via pull requests
- Approved code is merged into the main branch
- Everyone pulls the latest changes regularly
# Every team member's daily routine
git checkout main
git pull origin main
git checkout -b feature/my-task
# Work, commit, push
git push -u origin feature/my-task
# Open PR, get review, mergeSetting Up Team Conventions
Successful teams agree on conventions before they start coding:
Branch Naming
Commit Message Format
Many teams adopt Conventional Commits:
| feat | add user authentication endpoint |
| fix | resolve null pointer in payment processing |
| docs | update installation instructions |
| refactor | simplify database connection pooling |
| test | add integration tests for checkout flow |
| chore | update dependencies to latest versions |
Pull Request Standards
Define expectations for PRs:
- Maximum file changes (aim for under 400 lines)
- Required reviewers (at least one, preferably two)
- CI checks must pass before review
- PR description template must be filled out
Collaboration Workflows
Feature Branch Workflow
The most common pattern for teams:
# Developer A works on authentication
git checkout -b feature/auth
# ... commits ...
git push origin feature/auth
# Opens PR, requests review from Developer B
# Developer B works on dashboard simultaneously
git checkout -b feature/dashboard
# ... commits ...
git push origin feature/dashboard
# Opens PR, requests review from Developer ABoth developers work independently. Their branches do not interfere with each other. PRs are merged only after approval and passing tests.
Trunk-Based Development
For teams that ship frequently:
# Short-lived branches (1-2 days max)
git checkout -b quick-fix/button-color
git commit -am "Fix primary button color"
git push origin quick-fix/button-color
# PR is reviewed and merged same dayRelease Branch Workflow
For teams with scheduled releases:
# When ready to release
git checkout -b release/v2.1 develop
# Bug fixes go to release branch
git cherry-pick abc123
# When stable, merge to main and tag
git checkout main
git merge release/v2.1
git tag v2.1.0Code Ownership and CODEOWNERS
The CODEOWNERS file automatically assigns reviewers based on which files are changed:
When a PR modifies files matching these patterns, the specified teams are automatically requested for review.
Protecting the Main Branch
Branch protection rules prevent accidental damage:
- Require pull request reviews before merging
- Require status checks (CI) to pass
- Require branches to be up-to-date with main
- Restrict who can push directly
- Require signed commits
These rules ensure that main always contains reviewed, tested code.
Communication Patterns
Issue-first development: Before writing code, create an issue describing what you plan to do. This gives teammates visibility into upcoming changes and prevents duplicate work.
Draft PRs for early feedback: Open a PR early with the "Draft" label to get architectural feedback before investing too much time:
git push origin feature/new-approach
# Open as Draft PR with "RFC: New approach to caching" titlePR comments for async discussion: Not every question needs a meeting. Use PR threads to discuss implementation details — the discussion is preserved alongside the code for future reference.
Handling Conflicts in Teams
When multiple people modify related code:
# Before merging your PR, update your branch
git checkout feature/my-work
git fetch origin
git rebase origin/main
# Resolve any conflicts
git add .
git rebase --continue
git push --force-with-lease origin feature/my-workMinimize conflicts by:
- Keeping branches short-lived (merge within 1-3 days)
- Communicating about which files you are modifying
- Breaking work into independent, non-overlapping areas
- Pulling main into your branch frequently
Team Tools Integration
Connect GitHub with your team's communication:
- Slack integration — Get notifications for PR reviews, CI failures
- GitHub Actions — Automate testing, deployment, and notifications
- Project boards — Track who is working on what
- Status checks — Ensure code quality before merging
Common Team Challenges
Bus factor: If only one person understands a part of the codebase, require cross-reviews. Code reviews spread knowledge naturally.
Review bottlenecks: If PRs wait days for review, set team agreements (review within 24 hours) and rotate review responsibilities.
Merge conflicts: If conflicts are frequent, your architecture may need better modularity, or your branches live too long.
Key Takeaways
Effective team collaboration requires clear conventions (branch naming, commit formats, PR standards), proper tooling (branch protection, CODEOWNERS, CI), and good communication habits (issue-first development, timely reviews, async discussions). Git provides the technical foundation, but successful collaboration is ultimately about team agreements and discipline in following them consistently.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Team Collaboration with Git and GitHub.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.
Search Terms
git-github, git & github, git, github, collaboration, team, team collaboration with git and github
Related Git & GitHub Topics