Merge two features

Question

I have 1 branch in my project

1 - Master

I created 1 more branch and developed 1 Feature. I now have 2 branchs

1 - Master 
2 - feature1

I started to develop another Feature and now I have 3 branchs

1 - Master
2 - feature1
3 - feature2

I finished the first Feature and now I have 2 branchs

1 - Master
2 - feature2

But now I need Feature1 in the feature2 branch, because a feature2 feature depends on a feature that was implemented in Feature1.

What is the correct procedure to merge the branchs in this case, without I need to merge everything in master? I’m using the gitflow.

Answer 1

You are in a development stream called Feature-branch workflow. It’s good to know these names because so you can search for more specialized things on Google.

I really like Atlassian’s description of that worflow: https://www.atlassian.com/br/git/tutorials/comparing-workflows/feature-branch-workflow

In this specific case, there was a problem of lifting requirements before starting work. Why? Because the feature2 should only have been implemented after a basic code from feature1. You might not be able to solve this requirement problem before you start implementing it, because maybe you only realized this dependency when writing the code.

There are some alternatives to your situation. The most "basic" and it works for almost everything (not the best ever, though), is to do

$ git fetch && git merge origin/Master

in the branch feature2. Thus, you ensure that the requisite code is in the correct place.

Another alternative is to decrease delivery. As well?

Well, if it was possible to start the code from feature2 before that the code of the feature1, so that means there’s a part of feature2 that is independent of feature1. In that case, you could make a pull request/merge request of the independent code snippet. It will not deliver the Feature whole, but will take an important step in it. Only after mixing this code can you follow up on feature2-codigo-dependente-da-feautre1 on top of the branch Master already merged with that first part of feature.

There is another approach which is to try to keep the Feature branches all starting from the stable head, but for that it is necessary to give constants rebase after each merge. I know a team that works (more or less) like this (but with giflow, nay Feature-branch workflow), linear commit history looks beautiful, but how they work with "future" releases (maintainers in version 3.X generate rebase in 4.X [first future] that generates rebase in 5.X [second future] that generates rebase in 6.X [third and final future]), gets confusing retro-reference commits.

Particularly me, as code reviewer, I prefer at all times the solution that generates the greatest amount of merge requests with the smallest code differential in each merge request individual. Of course, provided that each merge request be self-contained and self-sufficient, and also be truly a logical unit of change. Perhaps these individual changes temporarily offend the YAGNI, but if the functionality as a whole needs to enter, the stable version of the code will not offend the YAGNI for long.

Answer 2

You can simply sync your branch feature2 with the branch master using the following commands:

$ git checkout feature2
$ git pull origin master

The fact that you perform the pull of your branch master to the feature2 will sync your branch with master, and consequently you will have the code of your feature1 in feature2 (since the feature1 is already in the master).

This operation may present conflicts, after the resolution you must generate a commit to finish the merge:

git commit