1

I am using git since long back and maintaining master, develop and feature branches. Now due to some bad merger our develop branch has some bad code. So, we have crated feature branch from master branch to work for particular feature.

After implementation of feature we have released this feature branch to prodoction which ideally we should not do. But because of bad code in develop we have released feature branch to production.

Now, I am working on some new feature and I want new feature branch for this new feature.

My Question is,

Is there any thumb rule or best practices which says don't create feature branch from feature or master ?

I dont want to create feature branch from other feature branch or master branch but I don't the exact reason why I should avoid this?

Ravi Parmar
  • 1,392
  • 5
  • 24
  • 46
  • 1
    Well, technically you can and sometimes you should. The main rule of thumb is that if feature B depends on some work made for feature A, then one should create that `feature/B` branch at an appropriate point of `feature/A`. But there're obvious caveats: branching that way a repo administrator essentially makes `feature/B` dependent on the fate of `feature/A`. So if something goes wrong with `feature/A` the same problems affect `feature/B`. In order to avoid chained problems, one should clearly understand release plans for both features – user3159253 Nov 28 '18 at 06:07
  • Sometimes it's advised to merge a current state of `feature/A` back to release branch (if it's stable enough) and then continue to work on both features independently. – user3159253 Nov 28 '18 at 06:07
  • Thanks ! it's a really meaningful comments – Ravi Parmar Nov 29 '18 at 06:35

2 Answers2

1

Considering that you already have master, develop and feature branches, it sounds to me that you are following the GitFlow Workflow. In that case, if you are working on some fixes or improvements to the last release, you could create hotfix branches, which are forked from master branch. Quoting from the Hotfix branches topic on the previous link:

Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they're based on master instead of develop. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch)...

This is just a suggestion for the GitFlow kind of branching model, that you can use while you stabilize the develop branch again.

The only reasons that I can think of to avoid creating a feature branch from another feature branch is trying to avoid forking from unstable branches (which is not your case), and to try to keep the history a little bit clean while following GitFlow or a similar workflow. But that is relative, because what you have at the end of the day on Git are linked commits instead of clear branches. Also, there is no real limitation to keep you away from forking feature branches from any branch/commit in your repo.

About your develop branch, in order to stabilize it, I would recommend to revert all the commits until the last known stable commit on develop, and then merge the head of master into the develop branch, if you are sure that master is stable. It probably won't look pretty on the Git history, but may do the job. Be careful and don't push the changes until you are sure about them.

Guillermo Gutiérrez
  • 17,273
  • 17
  • 89
  • 116
0

Feature-Branches are not bad, it’s how you utilize them.

In a Production Environment, you need at most one branch for deploy-able code and another for testing. To keep track of changes and whether those changes will work, you can further isolate changes away from the DEV branch. As you noted, someone introduced bad code, so you ought to prevent that.

Take the following Example:

Master Branch - Production-Ready Code Dev Branch - Testing Branch

  1. Feature-RevampMonitoring
    • Enhance-SQLAlerts
    • Bug-OSAlerts
  2. Feature-CompatibilityPatch
    • Bug-VERSIONAWARE

Notice that the Features are now broad categories of code and sub-branches are the individual sprints. Once the inner sprints are complete, we can roll them together in the Feature Branch, proof their validity, before merging into our Dev Branch where we can deploy on test environments.

So Features are good and can be used to encapsulate work, while also keeping the work focused.

clifton_h
  • 1,298
  • 8
  • 10