Proper way of working with and merging git branches

Question

I read a lot of articles, but still this is not clear to me. Let say I have project with two branches: master and dev. Dev holds the development branch and master the stable branch - with code ready to release.

Question 1:

I want to add some feature to dev branch - so I create another branch based on dev - let's call it: Feature/1/Some-feature-description, this feature is a big one, so I split it into three different branches: Feature/1.1/Some-sub-feature-description, Feature/1.2/Some-sub-feature-description and Feature/1.3/Some-sub-feature-description

So I started to work on feature 1.1, I have written some code, and in doing so, I have found a bug (not directly related to the sub feature 1.1 or the main feature 1), what should I do? I see few possible solutions:

1. Switch back to my dev branch, create another branch (Fix/1/Some-fix-description), fix the problem, merge the Fix branch into dev branch, switch to Feature 1 (main feature branch) merge changes from dev, switch to sub Feature 1.1 merge changes from dev.

2. Fix the problem inside Feature 1.1 (or perhaps create another fix branch based on Feature 1.1, fix the problem there and merge it back to Feature 1.1 branch), when the feature is complete - merge it with big Feature 1 branch, and when that is complete, merge it with dev.

Which is the proper (better) way to do it in single and multi developer project? Perhaps there is yet another way I'm not aware of?

Question 2:

After I have merged my Feature/1.1/ branch with Feature/1/, I found a bug in my Feature/1.1/ code, or I just want to make some changes there - is it OK, to switch back to Feature/1.1/, merge current Feature/1/ branch, make my changes and then merge them back to Feature/1/? Or should I create yet another branch based on current Feature/1/ code to do the changes ?

As always, thanks in advance for the answers.

Best regards.

Answer 1

Question 1:

I would say that option 1 is most in accord with git flow. Also, if the bug does not directly affect Feature 1 or Feature 1.1, it seems unnecessary to merge the fix to those branches. The important thing is that the fix will get delivered eventually, which it will as long as it has been merged to dev.

Question 2:

The strict git-flow way of doing it would be to make a separate fix branch. But I personally would do the fix on the old Feature 1.1 branch and merge it again to Feature 1. No need to merge Feature 1 to Feature 1.1 first.

Answer 2

I think it's okay to split the development of the feature into three different branches in order to organize the work in a best way.

So I started to work on feature 1.1, I have written some code, and in doing so, I have found a bug (not directly related to the sub feature 1.1 or the main feature 1), what should I do?

I agree with the second solution. Anyway you're still developing a feature that is not released. If this feature was already part of your master branch, then it would make sense to create a separate branch for the fix. For this reason I don't see any point to working using the first solution.

After I have merged my Feature/1.1/ branch with Feature/1/, I found a bug in my Feature/1.1/ code, or I just want to make some changes there - is it OK, to switch back to Feature/1.1/, merge current Feature/1/ branch, make my changes and then merge them back to Feature/1/? Or should I create yet another branch based on current Feature/1/ code to do the changes ?

I think the best and fast way is to create another branch on current Feature1 code, apply the fix and merge.

Note: What you're asking for are personal opinions about the way of the work. There's no guarantee or proof that each own personal way to create and merge branches is the best way. For each of us, our own personal way is the best.