0

I have a question concering git and git-flow.

I am working on a bigger software development project and I am using git (with git-flow) for version control. All works fine...

However, in the next month we have to deal with a bigger migration to another application server and therefore we have to do a lot of application server specific changes in our source code.

The migration process will take longer and therefore I need to have the possibility to maintain (hotfixes,...) the source code for both application servers.

Example (daily business):

  • Today: Rework on source code concerning the new server
  • Tomorrow: Hotfix for the current server
  • One day later: Small feature request for the current server
  • and so on...

Now, I don't know which would be the best strategy to handle this? Branching or forking or something else?

Georg Kastenhofer
  • 1,387
  • 12
  • 32

3 Answers3

2

Forking would result in a new repository which I don't think you want to be doing here.

If you are going to continue using gitflow, then you will want to follow the procedures for creating hotfixes. https://danielkummer.github.io/git-flow-cheatsheet/#hotfixes

You may find that using a separate branch for the new server might be better if you are going to continue to have feature requests for the current server. Just make sure that it stays up to date with the changes you are making for your current server.

Stout01
  • 1,116
  • 1
  • 10
  • 20
1

I'd create a new branch, still using the "old" branch as your main "to be released" branch (until the latest work has finished).

I would make new changes to the new branch, for those changes that need to remain separate, but if I needed to do any hotfixes I would fix the main branch and then cherry-pick those changes to the new branch.

Once the new branch is finished, I would merge back to the main branch and continue from there.

Apologies if that's too vague, I don't have a full picture of your project.

HomerPlata
  • 1,687
  • 5
  • 22
  • 39
0

Git-flow and multiple parallel releases

After some further investigations, I found a perfect solution for working with git-flow and multiple parallel releases (thanks to the author(s)):

If you want to fix bugs for older releases or do any other develop there, you will fork a support branch from the appropriate commit in master (you will have all versions ever created there)...

Git-flow and master with multiple parallel release-branches

Some other useful links:

Following git-flow how should you handle a hotfix of an earlier release?

https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches

https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches

https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J

Here an example of my future scenario:

State of my git-flow repository:

  • develop (work in progress for new application server)
  • master (last stable release)
  • v3.0.0 (final release for the old productive server)

If a bug in the old productive server will be reported, I have to do the following:

Used this git commands to add a hotfix to an earlier release:

git flow support start 3.x 3.0
git flow hotfix start 3.0.1 support/3.x

Now make your changes and then finish with:

git flow hotfix finish 3.0.1

If it is necessary to port a hotfix to your main development line (represented by master and develop), just start a hotfix, cherry-pick your changes and finish the hotfix.

Thats it...:)

Thanks to all mentioned contributors.

Community
  • 1
  • 1
Georg Kastenhofer
  • 1,387
  • 12
  • 32