Learning Objectives
- Understand different Git workflow strategies
- Learn when to use each workflow approach
- Master trunk-based development practices
- Implement effective branch management for teams
Understanding Team Workflows
Choosing the right Git workflow is crucial for team productivity and project success. Different workflows suit different team sizes and project requirements.
Workflow Factors
- •Team size and distribution
- •Release frequency
- •Project complexity
Common Approaches
- •Trunk-based development
- •Feature branch workflow
- •Forking workflow
Trunk-Based Development
Trunk-based development (TBD) is a source-control branching model where developers collaborate on code in a single branch called 'trunk', resist any pressure to create other long-lived development branches, and therefore avoid merge hell, do not break the build, and live happily ever after.
# Start work on main branch$ git checkout main$ git pull # Make changes and commit frequently$ git add .$ git commit -m "feat: add new feature with tests" # Push changes regularly$ git pull --rebase$ git push # Use feature toggles for incomplete workif (featureFlag.enabled('new-feature')) { // new feature code}
Advantages
- ✓Simpler workflow
- ✓Continuous integration
- ✓Faster release cycle
Best Practices
- •Small, frequent commits
- •Feature toggles
- •Strong testing practices
Feature Branch Workflow
The feature branch workflow uses separate branches for developing new features. This encapsulates work in progress and enables collaborative code review through pull requests.
# Create feature branch$ git checkout -b feature/user-authentication # Work on feature and commit$ git add .$ git commit -m "feat: implement user authentication" # Keep branch updated$ git fetch origin$ git rebase origin/main # Create pull request$ git push -u origin feature/user-authentication # After review and approval, merge$ git checkout main$ git merge --no-ff feature/user-authentication$ git push origin main
Key Practices
- 1.
Branch Naming
Use descriptive, categorized branch names (feature/, bugfix/, etc.)
- 2.
Regular Updates
Keep feature branches updated with main through rebasing
- 3.
Code Review
Use pull requests for team review and discussion
Forking Workflow
The forking workflow is common in open-source projects. Each developer has their own server-side repository, giving them more freedom to make changes without affecting the main project.
# Fork the repository on GitHub # Clone your fork$ git clone https://github.com/yourusername/project.git # Add upstream remote$ git remote add upstream https://github.com/original/project.git # Create feature branch$ git checkout -b feature/new-feature # Keep fork updated$ git fetch upstream$ git rebase upstream/main # Push to your fork$ git push origin feature/new-feature # Create pull request to upstream repository
When to Use
- •Open-source projects
- •Large, distributed teams
- •Projects requiring strict access control
Choosing the Right Workflow
Trunk-Based Development
Best for:
- •Small, experienced teams
- •Continuous deployment
- •Strong testing culture
Feature Branch
Best for:
- •Teams of any size
- •Regular releases
- •Code review process
Forking Workflow
Best for:
- •Open source projects
- •Large distributed teams
- •Public contributions