0

Hi search how to use feature-toggle long live feature with an short branching living strategy. It is advice to use short living branch (with PR and merge daily on master), but how to make this when your feature is long live. how to split your feature in multiple branch that make sense in git history.

I suggest to use versionning in branching name like this:

  • Create feature-A-v1 branch (toggle off in production)
  • PR
  • Merge
  • Delete feature-A-v1 branch
  • Create feature-A-v2 branch (toggle on in production)
  • PR
  • Merge
  • Delete feature-A-v2 branch

But on internet I don't find a sample like this, and I dont understand what is the good practice for make that.

ArDumez
  • 931
  • 6
  • 24
  • 1
    Don't merge in your branch until you're done with it, so keep it alive until you're done. You should instead merge periodically up into the branch if you expect merge conflicts to handle them in smaller pieces instead of a big conflict at the end, but nothing says you have to merge and delete branches daily. – Lasse V. Karlsen May 01 '17 at 11:00
  • When you say "merge periodically, you say master on feature or feature on master ?". But feature-toggle suggest merge branch on master whereas the feature is not done. So when I merge no finish feature on master, I should create a new branch to continue the feature... – ArDumez May 01 '17 at 11:36
  • 1
    You periodically merge the source branch of your feature branch into your feature branch. This will keep your feature branch "fresh" with changes introduced on its source (master, if that's where you originally branched from) and will let you manage merge conflicts while they're both small and fresh in mind of whoever introduced them. If you wait with merging until the end you risk have a potentially bigger merge conflict. – Lasse V. Karlsen May 01 '17 at 12:23
  • No, you should not merge your feature branch into master if it is not done. That's my point. Keep the feature branch separate and alive until you're done. You don't merge when a certain amount of time has gone by (a day), you merge because you want to introduce the changes into another branch. – Lasse V. Karlsen May 01 '17 at 12:24
  • You state: "It is advice to use short living branch (with PR and merge **daily** on master)". Whos advice is this? Sure, you use a short living branch if it's easy/quick to implement but you don't merge daily just because someone said so, you merge when you're done. – Lasse V. Karlsen May 01 '17 at 12:25
  • 1
    However, if you do want to merge your feature branch into master periodically, do so, just keep the branch alive and keep working on it. You can always merge more than once. – Lasse V. Karlsen May 01 '17 at 12:29
  • I search to make Trunk based developpement, but there are no clear documenation on this. I have start at my work with a feature-flag, but i find everything and its opposite to manage branch after first merge. thanks for your explanation, I think i make keep alive branch after merge or no make Trunk based developpement... I make continous delivery and my team has no clear workflow. – ArDumez May 01 '17 at 12:37

1 Answers1

0

Feature branch is usually used for developing new features or fixing bugs. So for different features/bugs you should use different feature branches and merge a feature branch into main branch until it is finished.

As you showed the process for feature-A-V1 and feature-A-V2, if the two feature branches developed for different features, you should do as you showed (they worked as short living branches). But the two branches developed for the same feature (feature-A), you should merge until feature-A is finished. In a way, we call it long living feature branch.

Working with long living branches, usually follow these steps:

1.Assume feature-A branch is checked out from production, and you are working on feature-A branch.

A---B---C  production
         \           
          D feature-A

2.During developing on feature-A branch, other developers update production branch, and the structure likes:

A---B---C---G---H  production
         \           
          D---E---F feature-A

3.After you finish developing feature-A branches, and before push and create PR, you can rebase feature-A branch to make sure it based on the latest version for production branch. You can use the commands:

git checkout feature-A
git pull origin production --rebase

And the structure will look like:

A---B---C---G---H  production
                 \           
                  D'---E'---F' feature-A

Now you can push feature-A to remote and create a PR to merge it into production branch.

And there has a successful branching module, you can refer.

Update

Since you need to merge and deploy feature-A-v1, and fix additional bugs but don't want to create new feature branch for this situation. You can checkout to feature-A-v1 branch, and fast forward it by merge production into feature-A-v1 (feature-A-v1 will also point to commit O in below graph). 

A---B---C---M---O  production
         \     /        
          D---N    feature-A-v1


A---B---C---M---O  production, feature-A-v1
         \     /        
          D---N
Marina Liu
  • 36,876
  • 5
  • 61
  • 74
  • but when I merge and deploy my feature work in the current stable state on master in v1, I want refactor my code, add more unit-test, correct bug fund by QA, and if I add a branch by task, there a large number of feature branch, and the pull request is very little, my collegue don't like this and I'm lost with all branch... – ArDumez May 02 '17 at 07:29
  • my team don't want a develop branch, – ArDumez May 02 '17 at 07:30
  • 1
    It's ok if you don't want develop branch, I give the link just for reference and different teams really have different branching model. And since you need to merge and deploy feature-A-v1, and fix additional bugs but don't want to create new feature branch for this situation. You can checkout to feature-A-v1 branch, and fast forward it by merge production into feature-A-v1. – Marina Liu May 02 '17 at 07:50