In my experience, the first thing you need to set before choosing a Workflow for git is what your cycle of releases .
The best model for your case depends on a main variable:
The code that is in production is continually changed with new
features as soon as they are ready (rolling release), or there is a
practice of incorporating all new features and bugfixes into one package
closed and release that for fixed release?
Note that in both cases it is crucial that new branches are created from the branch where they will be at the end of the process. Without intermediaries.
Rolling releases
This template is easy to use a less structured flow like Github Flow .
Having 2 main branches master and develop , all features are based on master . When they are ready they are incorporated into develop for homologation, and after release the feature is incorporated into master and released for production.
In this template develop is never embedded in master and often you delete develop and recreate from master when this branch gets "dirty" with changes that were never approved and will not be incorporated. Many companies prefer to call develop of staging in this case, to avoid confusion.
Fixed releases
In this case, a more structured process is worthwhile, such as Git Flow , illustrated in Diogo's reply.
In this process, the main branches master and develop serve different purposes than the previous flow. master is what you are running now, and develop is your next full release , meaning you know that code is stable and you are just waiting to finish the cycle to > all or develop in master . In this case then it makes sense that new branches are created from develop for developers to work on the most stable stable code.
In this process you often have other branches to test, for example a% of% where the test happens before the feature goes to staging and the important thing is that, at the beginning of each cycle, develop and develop be strictly equal.
