Feature Development Workflow

Feature Branch Workflow

The feature branch workflow is a Git workflow that promotes collaboration while ensuring the main branch always contains production-quality code.

Core Principles

1. Main branch is always deployable

   • The main branch (often called main or master) should always contain stable, production-ready code
   • Never commit directly to main in a collaborative environment

2. Feature development happens in dedicated branches

   • Each new feature or bugfix gets its own branch
   • Branches are created from the latest main branch
   • Work is isolated until the feature is complete

3. Integration through merge/pull requests

   • Changes are integrated back to main through merge requests (GitLab) or pull requests (GitHub)
   • This enables code review and discussion before integration
   • Automated tests can be run before merging

Workflow Steps

main branch: ----o----o----o----o----o----o----o----
                  \                      /
feature branch:    o----o----o----o----o

1. Update main branch

   git checkout main
   git pull origin main
   

2. Create a feature branch

   git checkout -b feature/user-authentication
   

3. Work on the feature

   # Make changes, then commit
   git add .
   git commit -m "Add user login form"
   
   # Make more changes
   git add .
   git commit -m "Add password validation"
   

4. Keep your feature branch updated

   # Option 1: Merge (safer)
   git checkout feature/user-authentication
   git merge main
   
   # Option 2: Rebase (cleaner history)
   git checkout feature/user-authentication
   git rebase main
   

5. Push your feature branch

   git push origin feature/user-authentication
   

6. Create a merge/pull request

   • Done through the GitLab/GitHub web interface
   • Assign reviewers
   • Add description of changes

7. Address review feedback

   # Make requested changes
   git add .
   git commit -m "Address review feedback"
   git push origin feature/user-authentication
   

8. Merge into main

   • After approval, merge through the web interface
   • Or use command line:

   git checkout main
   git merge feature/user-authentication
   git push origin main
   

9. Delete the feature branch

   # Delete local branch
   git branch -d feature/user-authentication
   
   # Delete remote branch
   git push origin --delete feature/user-authentication
   

Merge/Pull Requests Best Practices

Merge requests (GitLab) and pull requests (GitHub) are powerful collaboration tools that facilitate code review and discussion before changes are integrated.

Creating Effective Merge Requests

1. Keep changes focused and small

   • Smaller changes are easier to review
   • Aim for less than 400 lines of code per request
   • Each merge request should address a single concern

2. Write descriptive titles and descriptions

   • Title: Brief summary of what the change does
   • Description: Explain the why, not just the what
   • Include links to related issues or requirements

3. Add appropriate labels and assignees

   • Use labels to categorize the request (bug, feature, etc.)
   • Assign to appropriate reviewers

4. Include tests and documentation

   • Add tests that verify your changes
   • Update documentation if necessary

Example Merge Request Template

## Description
Brief description of the changes

## Related Issues
- #123 Feature request
- #456 Bug report

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## How Has This Been Tested?
Describe the tests you ran

## Checklist
- [ ] My code follows the project's style guidelines
- [ ] I have added tests that prove my fix/feature works
- [ ] New and existing tests pass
- [ ] Documentation has been updated

Reviewing Code

1. Be thorough but respectful

   • Focus on the code, not the person
   • Ask questions rather than making demands
   • Provide constructive feedback

2. Check for:

   • Functionality: Does it work as expected?
   • Code quality: Is it maintainable and readable?
   • Tests: Are there sufficient tests?
   • Security: Are there any vulnerabilities?
   • Performance: Will it cause performance issues?

3. Use inline comments for specific issues

   • Be specific about what needs to change
   • Explain why the change is needed

Advanced Workflow Concepts

Continuous Integration (CI)

Set up CI pipelines to automatically:

• Run tests
• Check code style
• Build the application
• Deploy to staging environments

# Example .gitlab-ci.yml
stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - npm install
    - npm test

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/

deploy:
  stage: deploy
  script:
    - deploy-script.sh
  only:
    - main

Protected Branches

Configure protected branches in GitLab/GitHub to:

• Prevent direct pushes to important branches
• Require merge requests for all changes
• Enforce code review approvals
• Require CI pipeline to pass before merging

Release Workflow

For more structured releases:

1. Maintain a develop branch

   • Feature branches merge into develop
   • Develop contains the latest development changes

2. Create release branches

   git checkout develop
   git checkout -b release/v1.2.0
   

3. Stabilize the release

   • Only bugfixes go into release branches
   • No new features

4. Merge to main and tag

   git checkout main
   git merge release/v1.2.0
   git tag -a v1.2.0 -m "Version 1.2.0"
   git push origin main --tags
   

5. Merge back to develop

   git checkout develop
   git merge release/v1.2.0
   git push origin develop