Skip to main content

🌿 Branching Strategies

  • Long Lived Master Branches: These branches serve as the main branches for ongoing development and act as the base for short lived branches. The commonly used long lived branches are:

    1. Main Branch: This branch represents the stable production code.
    2. Development Branch: This branch is used for ongoing development
    3. Release Branch: This branch is used for release preparation

  • Short Lived Master Branches: These branches are created for specific tasks such as feature development, bug fixes, refactoring, or experiments. They have a limited lifespan and are typically named using the format: (feat|bug|refactor)/task-slug. For example, feat/login-page.

  • Short Lived User Branches: These branches are created from and merged to the Short Lived Master Branches in the name of each users working on that feature development, bug fixes, refactoring, or experiments. they are typically named using the format: username/(feat|bug|refactor)/task-slug. For example, john/feat/login-page.

note

Use Short Lived User Branches only when more than one developer is working on the same task. otherwise, only use `Short Lived Master Branches``.

Avoiding conflicts

To avoid conflicts, it is recommended to merge the latest changes from the Long Lived Master Branches into the Short Lived Master Branches and Short Lived User Branches before pushing or merging your changes.

Branching Workflow​

  • Start by creating a new short lived master branch (feat/login-page) from the relevant long lived branch (main/dev) using the appropriate naming convention.

  • If you are working on a task with other team members, create a short lived user branch (john/feat/login-page) from the short lived master branch using the appropriate naming convention.

  • Make the necessary changes and commits in your short lived branch to implement the desired feature, fix a bug, refactor code, or conduct experiments.

  • Before pushing or merging your changes, ensure that you merge the latest changes from the master branches to avoid conflicts.

  • Once your changes are complete and tested, create a pull request or merge request to initiate the code review process.

  • Collaborate with your team members to review and approve the changes through merge requests.

Maintenance​

After the short lived branch is successfully merged into the long lived branch, it should be removed to keep the repository clean and manageable.