GitFlow and developing features for the next 2 releases

72 views
Skip to first unread message

craig....@gmail.com

unread,
Oct 11, 2016, 12:29:38 PM10/11/16
to gitflow-users
In my company we are considering moving to Git and piloting using GitFlow as our branching model.

Our code ultimately gets deployed to a production web server, so GitFlow seems like a good fit. However we have one scenario that is puzzling me.

Say we start adding new features to the next release (4.0), by creating feature branches that get merged back into develop when the features are complete. So far so good. However say we decided to start work on some features that are required for the 5.0 while the 4.0 release features are still being worked on.
I'm not sure how to solve this within the GitFlow branching model. Here are some thoughts I have had:

a) These 5.0 feature branches could be not merged into Develop until after the release_4.0 branch is created (when we think 4.0 is ready to ship) - but this doesn't really work for us because we want to be able to deploy and test all our 5.0 features together well before 4.0 is ready to ship. 

b) Do 'a' but do not create Feature branches for the individual 5.0 features and instead just have a 'features_for_5.0' branch. This would probably work, but doesn't sit well with me because then we are not using feature branches when developing features for 5.0 but are using feature branches when developing for 4.0.

c) Branch early for the Release_4.0 branch - I guess this would work but then all our features would be getting built on the 4.0 branch, so we could not create feature branches for them.

d) Go outside the GitFlow model and have an extra 'develop' branch called 'developPlus1' that all these 5.0 features are created in. This branch would allow feature branches to be created. Downside is I would then have to make changes to the gitFlow tooling to support this concept (unless it already exists and I'm not aware of it)

Any thoughts? Surely we can't be the only people wanting to develop the next 2 versions of a product at once. The reasons we would to do this is maybe a feature is bigger than normal so will take longer or are higher risk so we want them to bed in for longer.

Note I did see this thread, which is similar but it didn't seem to reach a conclusion.

Craig

Reply all
Reply to author
Forward
0 new messages