CODEWITHSUNDEEP
gitgithubversioninggit-flow
masimplo
masimplo

Reputation: 3774

How to work on two major versions using the GitFlow model

We have been working using the GitFlow model using feature/release/hotfix branches for quite some time. Now we are about to introduce a major feature that might take weeks to develop and is going to lead to a major version upgrade and we want to keep our current workflow for this major feature (thus not using a single branch where everybody commits directly) as well as the current version.

I am wondering what the best approach for this would be. Would it be to fork the entire repo and then merge back to the original? How can we keep both major versions under active development, thus have 1.x and 2.x gitflow workflows at the same time?

As a sidenote, the remote repository is hosted on github, so forking the whole repo under a certain user rather than a group, seems kind of counter-intuitive.

Upvotes: 4

Views: 1436

Answers (2)

pekaaw
pekaaw

Reputation: 2597

I sought an answer for this kind of situation as well and after a while I found a pleasing way to do it.

As @CodeWizard mentions:

by creating 2 develop branches one for day to day development and second one for your new product development line. All the changes committed to the original dev branch should also be committed to the new dev branch as well but not vice versa.

One approach to this is to let your long term branch behave like a new feature branch, for instance feature/next-major-version. When you want new features for the next major version, you simply create a new feature branch. The only change is that it should now branch out from feature/next-major-version, and not develop as it normally does.

To merge back sub-features, simply push the feature branch to GitHub and create a pull request from your sub-feature into feature/next-major-version. If it suits your needs, others can review your code. Nevertheless, in a GitHub pull request, you are allowed to merge from any branch into any other branch.

In our organization, we use git-flow through the amazing SourceTree program from Atlassian. From there it is possible to branch out like this. The challenge is that as of today, SourceTree does not seem to support merging a feature into another feature, only from a feature into develop. Adding GitHub pull requests to the work flow solves this problem.

Upvotes: 0

CodeWizard
CodeWizard

Reputation: 141946

A general comments just to clarify for users who are not familiar with git flow, git flow is an open source so you can modify the flow and customize it to your needs

Based upon the previous comment you have several choices on how to proceed from here:

  • As you suggested github fork is a good solution. git flow has the support branches for this case but they are marked as experimental feature at this moment.
    github fork will allow you to merge/export changes from the current dev branch to your parallel branch using web-hooks for example.

  • Modify the git flow to add a secondary flow as you required in your question ("thus not using a single branch where everybody commits directly") and when committing those changes you can decide what to do with it, where to merge it to based upon your new gitflow branch type.

  • You need to keep in mind and to be aware that if you are going to do a "major version upgrade you will have to "fix" a lot of conflicts on the way.

To summarize:
You can either choose to use git flow but then you will have to make sure that you are pulling very often to avoid huge conflicts later on by fixing them instantly when they occur
or
you can modify the gitflow and add customize it to your needs by creating 2 develop branches one for day to day development and second one for your new product development line. All the changes committed to the original dev branch should also be committed to the new dev branch as well but not vice versa.

Upvotes: 1

Related Questions