CODEWITHSUNDEEP
javagitversion-controlgit-flow
Dherik
Dherik

Reputation: 19120

Git branch strategy for feature branch model without a develop branch

My team have a problem to resolve about the best strategy for our case.

Our scenario

  1. Each feature have a separated branch
  2. We have a release branch created from master, to prepare the next version. The features that will be in the next release are merged in this branch. But, as I said, in the last moment some feature can get out of the version.
  3. Each feature, in the last moment, can get out of the version (release branch). We're not sure what feature will be in the next release. So, we cannot use something like a develop branch (as described in the Git Flow).
  4. The DBA team execute some scripts in production independent of the version. This scripts are commited on master, because they are already in production.

My sugestion

We are thinking to generated the version for test team from the release branch. If it's everything ok, we are thinking to merge the release branch into master, put a version tag (like 1.0) on master and generated the version from master branch using this version tag.

The only commmits in master that are not version commits is the SQL commits from DBA team. So, the generated version from release is equals from master.

But this is not approved for the whole team.

The fear

They have a fear about what branch we will use to generate the EAR. The EAR file generated in master branch is not exactly the same as the EAR file tested, because this is generated from release (another branch).

Another fear from my team is about someone commiting (or merging a feature) directly into master and the version generated on master have this unexpected commit. They are sure that will happen sometime.

Part of the fear happens because the DBA commits "mess" the master history. The master needs to be only the commit versions, but I don't know how to organize the SQL scripts from the DBA team that are independent of the version. Does not make sense these SQL scripts be released together with the next version, because these scripts are already executed in production database.

Solution (temporary?)

The solution, for now, is generate the version from release branch and use the same EAR from release branch in production. After that, the release branch will be merge into master and a new release branch will be created. The DBA SQL scripts will be continuing to be commited in master.

My opinion

I don't like this approach because:

  1. We lost the opportunity to have stable history in master with version tags containing only the version commits. I would like to bring a solution for this, but I don't know what to resolve the problem about the DBA SQL scripts.
  2. The fear is also based on merge errors in the past, where they used the (complicated) Subversion as version control.
  3. The version tags will be spread out on repository in different release branches.
  4. Is based on fear of some developer doing something wrong directly on master.
  5. This solution is contrary to almost all existing branch model, because it does not generate versions from the master. I have concerns about other problems that I cannot see now.

Even with these concerns, I cannot remove the fear and I understand their fear. I wonder if anyone has any different solution for our problem.

Updated

After the initial fear, we are generating the versions from master branch. After the test on the release branch, we merge the release branch in master and generate the version from there. So, all version tag remain in the master branch.

If some problem are detected in the release branch, we delete this branch and generate a new one, without the problematic functionality.

The DBA scripts, that are not related with some a specific funcionality, are executed independently and are saved in another repository now.

Upvotes: 1

Views: 587

Answers (1)

Scott Sosna
Scott Sosna

Reputation: 1413

First off, there needs to be some pretty good process discipline for any of this to work, it sounds like you've got a multiple-component application whose code base really isn't structured in a way to facilitate.

I do something like this: -master branch is source-of-truth and contains all completed features, only a build master/architect/whatever gets to merge/cherry-pick into this -release_x.y is a branch representing the final product for that release.

At the beginning of the dev cycle, the release branch is created from the previous release branch

Each feature team has its own branch created from master at whatever time they started their feature work. Anyone on the feature team can check into this branch.

When a feature is complete, the appropriate commits are cherry-picked/merged/squashed into master and the feature branch is deleted.

As feature are confirmed for a release, the commits are cherry-picked/merged/squashed into the release branch. Builds are done from the release branch.

If you have a bug fix for a previous release, use that release's branch to make the initial fix. At the very least, you'll need to cherry-pick the change into master, you might have to cherry-pick into other feature and/or release branches, depending on impact analysis

Another way to do feature development is to create separate team repos based on master at a given point in time. Depends on your preference, I like having separate repos that can be independently branched or tagged (such as sprints in an agile project). It also makes it easier for individual feature teams to exchange work-in-progress where there might be dependencies between them. In either case, you might need to bring updates to master into your team/feature repo, but it's doable.

However, you might just have a complicated source tree with a lot of coupling that, if removed, might make your source tree easier to manage

Upvotes: 1

Related Questions