👥 Collaboration Workflows

Gitflow Workflow

Gitflow is a classic branch management strategy, suitable for projects with planned version releases.

Gitflow Branch Structure:

main ─────●────────────────●───────────●─── (Production)
          │                ↑           ↑
          │                │           │
release ──┼──────●─────────┘           │
          │      ↑                     │
          │      │                     │
develop ──●──●───●──●──●──●──●──●─────┘──●── (Development mainline)
               ↑     ↑        ↑
               │     │        │
feature/xxx ───┘     │        │
feature/yyy ─────────┘        │
bugfix/zzz ───────────────────┘

Branch descriptions:
• main: Production code, only accepts merges from release and hotfix
• develop: Development mainline, convergence point for all feature branches
• feature/*: Feature branches, created from develop, merged back to develop when complete
• release/*: Release branches, created from develop, merged to main and develop after testing
• hotfix/*: Hotfix branches, created from main, merged to main and develop after fix

GitHub Flow — Simple is Beautiful

GitHub Flow is much simpler than Gitflow, suitable for continuously deployed projects.

GitHub Flow Process:

1. The main branch is always deployable
2. Create a descriptive branch from main (e.g., add-login-page)
3. Develop and commit on the branch
4. Open a Pull Request
5. Merge to main after code review passes
6. Deploy immediately after merge

main ──●──●──●──────●──────●── (Always deployable)
        ↑     ↑      ↑
        │     │      │
   feat/a ──┘     │
   PR + merge     │
                   │
         feat/b ───┘
         PR + merge

Forking Workflow — The Open Source Standard

In open source projects, you typically don't have direct push access. The workflow is:

# 1. Fork the repository on GitHub to your account

# 2. Clone your own fork
git clone git@github.com:yourname/open-source-project.git
cd open-source-project

# 3. Add the original repository as upstream
git remote add upstream git@github.com:original-author/open-source-project.git

# 4. Create a feature branch
git switch -c fix/fix-documentation-error

# 5. Develop, commit, push
git add .
git commit -m "docs: fix spelling errors in README"
git push origin fix/fix-documentation-error

# 6. Open a Pull Request on GitHub

# 7. Sync the latest code from upstream
git fetch upstream
git switch main
git merge upstream/main
git push origin main

Pull Request Best Practices

• One PR does one thing — don't add features, fix bugs, and refactor code all in one PR
• Write clear PR descriptions — explain what changed, why, and how to test
• Keep PRs small and focused — nobody wants to review a 3000-line PR
• Respond to review comments promptly — don't keep reviewers waiting
• Ensure CI passes before merging — don't let failing test code into main