Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

GitFlow: safely merge develop changes to a feature branch

Tags:

git

git-flow

Recently I started working on a big features, so I created a new feature/xyz branch. Problem is that this feature is big, so it will take me ~3 months to complete it. I would like to safely merge progress that has been made in develop to my feature branch, without worrying that changes from develop branch will override updates that I already made in my feature branch. My previous attempt to merge develop to feature/xyz ended up in some changes that I already made in the new feature being reverted.

What would be the command to achieve this? Thanks

like image 640
Ilija Avatar asked Feb 09 '14 15:02

Ilija


People also ask

What happens to feature branch after merge?

The answer is: nothing happens to the feature branch as a result of the merge. The new merge commit is added on the current branch (which is master when the merge is done).


2 Answers

The only safety is in learned, discerning and frequent merges.

Only you understand how the code on develop and feature/xyz aligns, no one else. It is only you who can merge the two flows correctly in a discerning way. Even with the default merging strategies, which are far less dangerous than -S ours or -X theirs you still always have to review the result.

You may need some help of course, and git will offer some. For example, you can use git recorded resolutions - rerere to help with making the same correct merge decision after you made one initially.

A fairly common, and relatively simple model, using the names you’ve supplied for the branches, could work for you like this,

  • develop is the branch where the main thrust of development occurs
  • xyz is the branch where you develop the feature xyz
  • xyz_stage is the branch where you merge the develop and the xyz code, keeping that branch stable in line with the respective stable points of develop and xyz. This is also the branch that you’d eventually merge back into develop when you are ready to release feature xyz or part of thereof.

The above assumes that not only you merge xyz into xyz_stage but that you also merge develop into xyz_stage from time to time and make sure that the portions of xyz so far released to xyz_stage work and pass the relevant tests in conjunction with the code from develop.

Nevertheless, you still have to choose how do you make the xyz branch, where you work on the feature, aware of the progress on develop.

The cleanest option is - don’t make it aware. That’s why you have xyz_stage where the two development flows come together. This approach is feasible and sane as long as the development of xyz is not prolonged.

The second option is to merge xyz_stage back into xyz when you are happy with the staging branch. That way you will have stable point that you can continue and develop the xyz feature on top.

Here's a simple illustration of the process, with comments:

Feature xyz

like image 140
mockinterface Avatar answered Sep 20 '22 11:09

mockinterface


In my experience, the only "safe" solution is to always manually inspect and test the result of any merge. --no-commit will stage the merge and let you inspect it before committing, or you can reset/amend, whatever feels more practical. Getting a three-way-merge tool can be very helpful. There are just too many ways things can break without there being merge conflicts, that relying on automatic merging is bound to get you into trouble. If you have 100% test coverage, sure, you can be a bit more relaxed, but how many projects can really claim that? ;-)

like image 32
axl Avatar answered Sep 17 '22 11:09

axl