Team Characteristics:

• Team fixed to 12 people (10 developers)
• Maybe: QA team added

Project Characteristics:

• “Full” project delivery in 3 months

Possible Branch workflows

• Trunk based development: All development is small and incremental and takes place directly on the main branch (Need strong automated testing and CI)
• By Feature: Encapsulates each new feature in a dedicated branch (parallel development of multiple features, easier code review, unsures main stable)
• By Release: Each branch provides a release (flexibility; stabilize code, last-minute bugs or changes, final testing)

Guidelines

Pull request guidelines

• You've little or no code but want to share screenshots or general ideas.
• You're stuck and need help or advice.
• You're ready for someone to review your work.

Using the @mention system in your Pull Request message, you can ask for feedback from specific people or teams, whether they're down the hall or 10 time zones away.

Branches

• The main branch:
  • The main branch has protected branch policies.
    • Any changes to the main branch flow through pull requests only
    • Minimum 1 review and approve (other than PR request member).
    • Check for PR comment resolution
    • Check for linked work items (issues, stories acceptance criteria)
    • Squash merge: Only one commit per merge
    • CI/CD
      • Build validation
      • Test validation?
      • Automatically include reviewer
  • The main branch is the only way to release anything to production.
  • The main branch should always be in a ready-to-release state.
  • Tag all releases in the main branch with Git tags.
• The feature branch:
  • Use feature branches for all new features and bug fixes.
  • Use feature flags to manage long-running feature branches.
  • Changes from feature branches to the main only flow through pull requests.
  • Name your feature to reflect its purpose.
• The release branch:
  • Create a dedicated release branch from a stable feature branch to prepare for deployment.
  • Ensure the release branch undergoes thorough testing and stabilization efforts.
  • Apply bug fixes and necessary changes to the release branch before deployment.
  • Tag releases in the release branch to mark significant milestones.

Branch naming convention

//Branches examples: Naming convention
bugfix/description
features/feature-name
features/feature-area/feature-name
hotfix/description
users/username/description
users/username/workitem

Pull requests checklist example

• Has released github issue or create issue
• Tested it
• Passed local linter with team configuration
• Read the PR collaboration guide (check naming conventions for commits and pr)

More options: Gitflow workflow

Gitflow is a legacy Git workflow that was originally a disruptive and novel strategy for managing Git branches. Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices. Gitflow also can be challenging to use with CI/CD. This post details Gitflow for historical purposes.

Compared to trunk-based development, Gitflow has numerous, longer-lived branches and larger commits. Under this model, developers create a feature branch and delay merging it to the main trunk branch until the feature is complete. These long-lived feature branches require more collaboration to merge and have a higher risk of deviating from the trunk branch. They can also introduce conflicting updates.