8 thoughts on “Git Flow, bringing sanity to teams.”
The thing I’m not getting, here, is: why is the leftmost ‘future feature’ branch not merged back into dev at least at time of each release? It would seem to save trouble, instead of having that work sit out there on the branch as dev (and the release branch, and master) keep evolving, making the eventual merge more complicated.
If they diverge a lot then yes there could be a conflict by the time it gets merged back. The longer it sits there parked in a branch the more likely that is.
However usually a feature branch differs from develop in only a few lines in a few files and folders. ie. it usually has a relatively small surface area of potential conflict therefore it’s not usually something too hard to deal with.
Only those files that change need to be staged for committing so the diff is usually small between the feature branch and develop.
Also the method of merging (no fast forward) is to preserve all history so merging is not so destructive and is easier to undo.
Re-read the article, but still do not get why there’s a need for two main branches with an infinite lifetime. There are tags to track sequence of production releases that can be done in either of the branches.
Well you could do without one of them I guess but I don’t think it hurts to have two. The alternative is to have release branches that don’t merge to master.
John Hardy Developer 
The thing I’m not getting, here, is: why is the leftmost ‘future feature’ branch not merged back into dev at least at time of each release? It would seem to save trouble, instead of having that work sit out there on the branch as dev (and the release branch, and master) keep evolving, making the eventual merge more complicated.
LikeLike
What’s the purpose and use of master branch?
LikeLike
If they diverge a lot then yes there could be a conflict by the time it gets merged back. The longer it sits there parked in a branch the more likely that is.
However usually a feature branch differs from develop in only a few lines in a few files and folders. ie. it usually has a relatively small surface area of potential conflict therefore it’s not usually something too hard to deal with.
Only those files that change need to be staged for committing so the diff is usually small between the feature branch and develop.
Also the method of merging (no fast forward) is to preserve all history so merging is not so destructive and is easier to undo.
LikeLike
The master branch is a sequence of production releases.
LikeLike
The other way to ensure that the merge is easier to roll back is to squash sequences of commits into a single commit.
git reset –soft
git commit -m “description”
git push -f
This makes the diffing neater
LikeLike
Furthermore before merging you can rebase the branch on the current state of develop. This applies your changes after all other changes.
Again the diff consists usually of only a few lines changes in a few files so the violence of your edits and the likelihood of a conflict remain low.
Edit: multiple typos fixed
LikeLike
Re-read the article, but still do not get why there’s a need for two main branches with an infinite lifetime. There are tags to track sequence of production releases that can be done in either of the branches.
LikeLike
Well you could do without one of them I guess but I don’t think it hurts to have two. The alternative is to have release branches that don’t merge to master.
LikeLike