Multi-person collaborative workflow

Basic Concepts of Multi-Person Collaborative Workflow

Multi-person collaborative workflow is a crucial aspect of software development. Git, as a distributed version control system, provides powerful tools to support team collaboration. Team members can work simultaneously on different branches and integrate code through merging and pull requests. This working model requires clear rules and processes to avoid conflicts and chaos.

Centralized Workflow

The centralized workflow is the simplest collaboration model, suitable for small teams or developers new to Git. It has only one central repository, and all developers commit code directly to the master branch.

// Developer A's workflow
git clone https://github.com/project/repo.git
git checkout -b feature-A
// Develop code...
git add .
git commit -m "Implement feature A"
git push origin feature-A

The drawback of this workflow is that it can easily lead to conflicts, especially when multiple people modify the same files simultaneously. Resolving conflicts requires developers to frequently pull the latest code from the central repository:

git pull origin master
// Resolve conflicts...
git add .
git commit -m "Resolve merge conflict"
git push origin feature-A

Feature Branch Workflow

The feature branch workflow improves upon the centralized workflow by creating independent branches for each new feature. The main branch (master) remains stable, and all development occurs on feature branches.

// Create a new feature branch
git checkout -b feature-login master
// Develop login feature...
git add .
git commit -m "Implement login interface"
git push origin feature-login

Teams typically use Pull Request or Merge Request mechanisms for code review:

1. Developers push feature branches to the remote repository
2. Create a Pull Request to merge into master
3. Team members review the code
4. After approval, merge into the master branch

Git Flow Workflow

Git Flow is a more structured branching model with strict branch roles and merging rules. It includes the following main branches:

• master: Production environment code
• develop: Integration development branch
• feature/*: Feature development branches
• release/*: Pre-release branches
• hotfix/*: Emergency fix branches

// Start new feature development
git checkout -b feature/search develop
// Develop search feature...
git add .
git commit -m "Implement basic search feature"
git checkout develop
git merge --no-ff feature/search

Release process example:

git checkout -b release/1.0 develop
// Fix bugs, prepare for release...
git checkout master
git merge --no-ff release/1.0
git tag -a 1.0
git checkout develop
git merge --no-ff release/1.0

Forking Workflow

The Forking workflow is common in open-source projects, where each developer has their own remote repository copy. The workflow is as follows:

1. Developers fork the main repository to their own account
2. Clone a local copy
3. Create a feature branch
4. Push changes to their own remote repository
5. Create a Pull Request to the main repository

// Developer operations
git clone https://github.com/yourname/repo.git
git remote add upstream https://github.com/main/repo.git
git checkout -b fix-bug
// Fix bug...
git add .
git commit -m "Fix login bug"
git push origin fix-bug
// Then create a PR on GitHub

Code Review and Merge Strategies

Effective code review is key to multi-person collaboration. Teams should establish clear review standards:

1. Code style consistency
2. Feature completeness
3. Test coverage
4. Performance considerations
5. Security checks

The choice of merge strategy is also important:

// Avoid fast-forward merges to preserve branch history
git merge --no-ff feature-x
// Rebase to maintain linear history
git rebase master
// Interactive rebase to tidy up commits
git rebase -i HEAD~3

Conflict Resolution Strategies

Conflicts are inevitable but can be minimized by:

1. Frequently merging or rebasing from the main branch
2. Small, granular commits
3. Clear commit messages
4. Team communication

Steps to resolve conflicts:

git fetch origin
git rebase origin/master
// When conflicts occur...
// Manually resolve conflicted files
git add conflicted-file.js
git rebase --continue
// To abort the rebase
git rebase --abort

Continuous Integration and Automation

Integrating Git workflows with CI/CD tools can greatly improve efficiency. For example, GitHub Actions configuration:

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - run: npm install
    - run: npm test
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - run: npm install
    - run: npm run build

Large Team Collaboration Practices

For large teams, consider the following optimizations:

1. Modular codebase
2. Submodule or monorepo management
3. Tiered code reviews
4. Automated test coverage
5. Code ownership mechanisms

Example using Git submodules:

git submodule add https://github.com/team/ui-components.git
git commit -m "Add UI components submodule"
// Update submodules
git submodule update --remote

Branch Naming Conventions

Good branch naming conventions improve collaboration efficiency:

• feature/user-login
• bugfix/login-page-error
• hotfix/payment-failure
• experiment/new-algorithm-test
• release/v1.2.0

// Create a branch following conventions
git checkout -b "feature/user-profile"

Commit Message Standards

Meaningful commit messages help teams understand changes:

Type(Scope): Brief description

Detailed explanation of changes and impacts

Related issue: #123

Possible types:

• feat: New feature
• fix: Bug fix
• docs: Documentation changes
• style: Code style
• refactor: Refactoring
• test: Test-related
• chore: Build or auxiliary tools

Permission Management and Protected Branches

Protecting important branches is necessary:

1. Set master/main as protected branches
2. Require Pull Requests
3. Require code reviews
4. Require passing CI tests
5. Restrict direct push permissions

GitHub branch protection settings example:

1. Settings → Branches → Branch protection rules
2. Add rules to protect the master branch
3. Enable "Require pull request reviews"
4. Set the number of "Required approving reviews"
5. Enable "Require status checks to pass"

Distributed Team Collaboration Tips

For cross-timezone teams:

1. Clear asynchronous communication processes
2. Detailed PR descriptions
3. Use labels to categorize issues
4. Regular video meetings
5. Shared documentation for decisions

// PR template example
## Change Description
[Detailed description of changes]

## Testing Steps
1. [Step 1]
2. [Step 2]

## Screenshots/GIFs
[Optional]

## Related Issue
Close #123

Performance Optimization and Large Repositories

Tips for handling large Git repositories:

1. Use shallow clones

git clone --depth 1 https://github.com/large/repo.git

2. Regularly perform garbage collection

git gc --aggressive

3. Use sparse checkout

git sparse-checkout init
git sparse-checkout set src/components

4. Consider splitting into submodules

Hook Scripts and Automation

Git hooks can automate workflows:

// pre-commit hook example
#!/bin/sh
npm run lint
if [ $? -ne 0 ]; then
  echo "Lint check failed, please fix errors before committing"
  exit 1
fi

Common hooks:

• pre-commit: Checks before committing
• commit-msg: Validates commit messages
• pre-push: Runs tests before pushing
• post-merge: Installs dependencies after merging

Visualization Tools Assistance

Graphical tools can help understand complex histories:

1. Graphical git log

git log --graph --oneline --all

2. Use gitk or GitHub Desktop
3. IDE-built-in Git tools
4. Third-party visualization tools like SourceTree

Emergency Handling and Recovery

Common issue resolution methods:

1. Undo local changes

git checkout -- file.js

2. Reset to a specific commit

git reset --hard HEAD~1

3. Restore accidentally deleted branches

git reflog
git checkout -b recovered-branch abc123

4. Amend the most recent commit

git commit --amend

Documentation and Knowledge Sharing

Teams should maintain the following documents:

1. Git workflow standards
2. Branch strategy explanations
3. Code review guidelines
4. Common issue resolutions
5. Best practice examples

Documents should be placed in the project root directory:

/docs
  /workflow.md
  /code-review.md
  /git-cheatsheet.md