Branching Strategy - AEDRA-TG/AEDRA GitHub Wiki

Introduction

This page describes the branch strategy to be used on the repository of the AEDRA project.

Branching Strategy

  • Master: the code that is deployed to the production environment to be shown to the client.
  • Development: Integration of the code worked per feature and a staging branch to ensure that everything works before merging to master.
  • Feature per Jira: consists in the code, using TDD methodology, related to each user story of a Jira ticket.

Git Flow

Branch naming convention

  • Feature per Jira:

feature/<sprint>_<featureName>_<userStoryID>

configuration/<sprint>_<userStoryID>

bugFix/<sprint>_<featureName>_<userStoryID>

Branching creation

  1. A develop branch is created from master at the beginning of the project.
  2. A feature branch is created from the develop branch for each user story to be implemented.
  3. A configuration branch is created from the develop branch for each configuration needed in the project.
  4. A bugfix branch is created from the develop branch for each bug to fix.

Merging branches

  1. Each feature must merge with development solving conflicts if it’s necessary.
  2. The development branch merges to master ensuring completely functional code.

Rules

  1. Before merging a feature branch to the development branch, team members should pull changes from the development branch to the feature branch to solve conflicts.
  2. Each day the changes committed on the feature branch should be pushed to the git.
  3. Make commits often per each relevant code block done.
  4. Each feature branch should be merged to development branch at the end of each sprint.
  5. Development branch should be merged to master branch two times, when generic features are finished and when the application is completed.
  6. Each time master is modified, the system is deployed.
⚠️ **GitHub.com Fallback** ⚠️