1. What Is Collaborative Development?
Collaborative software developmentis the process where multiple software engineers write, review, test, and integrate code into a single shared codebase without overwriting each other's work.
2. How Developers Work Together With Git
Small-to-medium teams push branches directly to the central company repository and open PRs.
Open-source contributors fork their own copy and submit PRs back to the upstream repo.
GitHub Actions automatically run tests and linters before anyone is allowed to merge.
3. Forks and Cloning (Upstream vs Origin)
| Concept | Where It Lives | Purpose |
|---|---|---|
| Upstream | Original organization GitHub repo | Canonical source of truth (read-only for outside contributors) |
| Origin (Fork) | Your personal GitHub account | Your cloud copy where you have write access to push branches |
| Local Clone | Your personal laptop / PC | Where you edit code, run local dev servers, and make commits |
4. Feature Branch Workflow
Always branch off the latest main with a standard naming convention:
git switch main && git pull origin main
# 2. Create feature branch
git switch -c feat/user-authentication
# 3. Work, test, commit atomically
git add .
git commit -m "feat(auth): implement JWT token storage"
# 4. Push to remote
git push -u origin feat/user-authentication
5. Pull Requests (PR Lifecycle)
A Pull Requestis not just code; it's a technical proposal. Write clear PR descriptions:
- Added user authentication modal with email validation.
- Integrated Supabase Auth client.
## Related Issue
Closes #24
## How to Test
1. Open `/login` ➔ click "Sign in with Email" ➔ verify toast feedback.
6. Code Reviews: Reviewing & Handling Feedback
Code is clean, tested, and ready to merge into production.
Non-blocking feedback or questions about architecture decisions.
Blocks merge until critical bugs, security issues, or missing tests are resolved.
7. Handling Collaboration Conflicts
When teammates merge their PRs first, your branch might fall behind. Keep your branch synced:
git switch main
git pull origin main
git switch feat/my-work
git merge main
# (Resolve any conflicts if prompted, then git commit && git push)
8. Issues, Labels & Auto-Closing (Closes #24)
Using keywords like Closes #24, Fixes #10, or Resolves #102 in your PR description tells GitHub to automatically move and close the associated issue when the PR merges.
9. Permissions & Protected Branches
In production teams, repository admins protect the main branch with rules:
- Require at least 1 or 2 approved peer reviews.
- Require all automated CI test suites to pass.
- Require linear commit history (Squash and Merge).
- Disable force-pushes (
git push --force).
10. A Complete Team Workflow Summary
2. git switch -c fix/24-nav-overflow
3. Code ➔ test ➔ git commit -m "fix(nav): resolve mobile overflow (#24)"
4. git push -u origin fix/24-nav-overflow
5. Open PR: "Fix mobile navigation overflow (Closes #24)"
6. CI runs test suite (Green ✓)
7. Senior Reviewer leaves feedback ➔ Update branch ➔ Approved ✓
8. Squash and Merge ➔ Issue #24 auto-closes ➔ Deploy to production!
11. Common Collaboration Mistakes
- Ghosting code reviews: Respond to review comments promptly with explanations or fixes.
- Giant PRs with 50 changed files: Split large features into smaller, reviewable PRs (< 300 lines).
- Taking feedback personally: Code reviews critique the code, not the engineer. It is how developers grow together.
12. Collaboration Best Practices
- Write clear, helpful PR descriptions with before/after screenshots for UI changes.
- Delete merged feature branches to keep the repository uncluttered.
- Use Conventional Commits (
feat:,fix:,docs:,refactor:).