Collaboration Workflow

Without a defined workflow:
• Developers overwrite each other's work
• Conflicts become frequent and complex
• Code quality drops
• Releases become unpredictable

A workflow answers:
• Where do features go?
• Who can push to main?
• How are changes reviewed?

2.1 Feature Branch Workflow
Most common and beginner-friendly.
Flow:
main
└── feature/xyz
Steps:
1. Create a feature branch
2. Commit changes
3. Push branch
4. Open Pull Request
5. Merge after review
Best for small to medium teams.

2.2 Git Flow
More structured, used in release-heavy projects.
Branches:
• main → production
• develop → integration
• feature/*
• release/*
• hotfix/*
Pros:
• Clear separation of work
Cons:
• Heavy for small teams

2.3 Trunk-Based Development
Advanced, used in high-velocity teams.
• One main branch (main)
• Very short-lived branches
• Frequent merges
Requires:
• Strong CI
• Feature flags
• Discipline

Pull Requests are the core collaboration mechanism.

They provide:
• Frequent merges
• Automated testing
• Discussion
• Approval gates

Typical PR rules:
• Small, focused changes
• Clear description
• Linked issue/ticket
• At least one reviewer

Before pushing or opening a PR:
This:
• Reduces conflicts
• Makes review easier
• Keeps history clean

Conflicts happen when two people change the same lines.

Best practices:
• Pull frequently
• Keep branches short-lived
• Resolve conflicts locally
• Test after resolution

Never resolve conflicts directly on GitHub unless trivial.

Do
• Commit small, logical changes
• Write meaningful commit messages
• Pull before starting work
• Communicate before major changes

Don't
• Force push to shared branches
• Commit directly to main
• Keep long-running branches
• Ignore CI failures

• Collaboration workflows prevent conflicts and chaos.
• Feature-branch workflow is the most common and beginner-friendly.
• Pull Requests are central to team collaboration.
• Keeping branches up to date reduces merge conflicts.
• Clear rules and communication matter more than Git commands.