Doubt in git usage

Question

We’re migrating our version control from Subversion to Git.

I’m finding the following problem, we have a large project with several developers, our flow uses the branches: Master, Develop and Feature.

When we have to make a new customization a new one is created branch Feature based on Develop and customization is developed, but when another developer has to do another customization he follows the same step, created another branch Feature based on Develop.

When the developer finishes the customization is made a merge among the branches Feature and the Develop and is released for user to perform validation.

The problem is that I eat both Features are in the branch Develop when migrating to the Master would like to take only one Feature and not the Develop entire.

I wonder if our flow is wrong, if that’s how you work with Git.

Answer 1

Best git workflow tutorial I’ve ever read: Comparing Workflows

In my opinion are missing two important branch in your project: Release and the Hotfix

Answer 2

New branches always start master. Up to a branch dev, feature or patch be in the master much can happen. Commits can change, there can be commits of branches dev that after all are no longer going to be used, someone can force push and spoil the history of commits by getting duplicated with different hashes, etc.

What’s in the master is guaranteed (and common to all branches/branches), what comes again must receive a rebase (for commits to be re-ordered) and then enter the master.

It is good to separate concepts and think/decide what each branch does. Having a dev branch for months where everything stops and then merging into master usually causes problems. Short iteration cycles are best. This means that the dev branch is not always active.

A model tested and what use is:

• patch branch: 1 to 5 commits, some urgent correction
• Feature branch: 1 to 50 commits (more than this should perhaps be left in pieces)
• dev branch: 1 to 30 commits, to go managing nonurgent problems and backlog, always trying not to press more things than necessary

All 3 branches do merge directly on master when they are ready, and at that moment the other branches that are active make a rebase at the master to import commits that have entered the master.

Answer 3

In my experience, the first thing you need to define before choosing a workflow for the git is what your release cycle.

The best model for your case depends on a main variable:

The code that is in production is continuously changed with new Features as soon as they are ready (rolling release), or there is a practice of incorporating all the new Features and bugfixes into one package closed and release this for production (Fixed release)?

---

Note that in both cases it is crucial that new branches are created from the branch where they will be embedded at the end of the process. No intermediaries.

---

Rolling releases

This phallic model uses a less structured flow like the Github Flow.

Having 2 main branches master and develop, All Ports are based on master. When they are ready they are incorporated into develop for approval, and after release to Feature is incorporated into master and released for production.

In this model develop is never incorporated into master and often you delete develop and recreates from master when that branch gets "dirty" with changes that have never been approved and will not be incorporated. Many companies prefer to call the develop of staging in this case, to avoid confusion.

Fixed releases

In this case a more structured process is worth, as the Git Flow, illustrated in Diogo’s reply.

In this process, the main branches master and develop serve purposes other than the previous flow. master is what you’re running now, and develop is your next full release, that is, you know that that code is stable and is just waiting to complete the cycle to incorporate whole the develop in master. Then it makes sense that new branches are created from develop for developers to work on stable code most current.

In this process you often have other test branches, for example a staging where the test takes place before Feature goes to develop and the important thing is that at the beginning of each cycle, develop and master are strictly equal.