Skip to content
This repository has been archived by the owner on Dec 1, 2023. It is now read-only.

General introduction

osj2507 edited this page Apr 26, 2013 · 3 revisions

In general we should have two big branches, feature branches, bug and hotfix branches, I suggest these to be and be named as the following.

Master

Staging

Feature-branches

Bug-Hotfix-branches

It is important to mention that if you don't have a local master branch it is easier to keep your code in sync and impossible to ruin remote master by accidentally pushing your own.

Master is the one that is the production branch, so all branches are made from this and merged back into this when approved for live environment.

Staging is the testing branch, before putting any feature on Master it should have been on staging and tested that it works and that the existing code doesn't break or doesn't work as it should after the feature have been merged.

Feature are branches for a specific feature, we are able to make as many branches as possible, and it is better to keep features in one big branch til it is ready and can be tested and released. As one big feature instead of small features that depend on each other and can't be included in master on its own, it wil be better code structure.

Bug & hotfix are also branches but for a specific bug and if it is critical a hotfix. Bug and hotfix branches can belong to a feature branch or to the master branch, if the code is not yet released but a bug is found on staging it should be made from the feature branch it belongs to. If the feature is live and a bug is there it can either be a bugfix that is released at next live publish or a hotfix that needs to go live immediately.

Since features can change the same files or parts of them, it is important that we use rebasing to check for other changes and getting the best possibilities of automatic merging features into staging and master.