2

Currently we are planning to switch from our software version 5.x.x to 6.x.x. Such major releases contains in our case a lot of refactoring work and changing the software architecture. Instead of creating a new branch for version 6 (git), I thought to create a custom repository for this. In general, developing the new version bases on the old version, so it would be a copy.

My problem is that developing version 5 will not stop, because bug fixes and a few minor changes will be done. But now I have two versions I am working on, in two separate repositories. What is the best way to make changes in both, without copy code, or do the work twice? Is there some effective way?

Maybe some one else has the same issue before.

gnat
  • 21,442
  • 29
  • 112
  • 288
BendEg
  • 149
  • 5
  • 10
    In Git, branches and repository copy are essentially the same thing. There is no need to completely separate the two development branches. With that in mind, why don't you want to create a new branch for v6? What problems do you anticipate? Why do you want a separate repository? I can think of a couple of nice solutions, but you have to specify your problem more precisely. – amon Nov 29 '15 at 14:13
  • 1
    Switching to a new reposity might cause you to loose revision history, or at least make it more difficult to access the history. At my shop we often run into question like "why has this been done in this way?", "who did it?", and "how long has this feature/bug existed?". Why do you want to lose this information and start a separate repository? – Kasper van den Berg Nov 29 '15 at 14:40
  • I only thought it will be more clean when seperating those projects. But if you think branching is better, than i would do this. – BendEg Nov 29 '15 at 14:40
  • @KaspervandenBerg you are correct. Starting a new repository will cause trouble. Thank you! – BendEg Nov 29 '15 at 14:46

2 Answers2

8

One common way to handle this scenario is to use a trunk/branch concept. What you do is have the single repository and branch the 5.x.x version for maintenance reasons. Then you put all of the your new 6.x.x changes into the trunk. That way you maintain all of the version history of your code. This also allows you to check out the old version and make a targeted fix there without impacting the trunk.

Here is what this would look like:

                                                |------branch (5.x.x)
                                                |
----------------------------------------------------------------------Trunk (6.x.x)

Then later if you ever need to have a version 7.x.x you could do the same again:

             |------branch (5.x.x)
             |                             |---branch (6.x.x)
             |                             |
---------------------------------------------------------Trunk (7.x.x)
barrem23
  • 3,161
  • 23
  • 21
  • This seems to be a good solution. Than you very much! Currently i have a master branch, which contains the current release, a dev brunch which contains the current development version, and feature brunches, which will be merged to the dev branch. So i would make the current master branch to trunk, and from this branch i create branches for the old version, (5.x...). Thank you! – BendEg Nov 29 '15 at 14:45
  • 2
    dev brunch sounds nice – Lightness Races in Orbit Nov 29 '15 at 16:01
  • The only reason to not do this is when your repository got to large. In this case setting up a new one is a good idea. – Lothar Nov 29 '15 at 18:51
2

Several solutions are together with git. I have get good experiences with git-worktree for such situations. Excerpt from the manual pages:

Manage multiple working trees attached to the same repository.

A git repository can support multiple working trees, allowing you 
to check out more than one branch at a time. With git worktree add
a new working tree is associated with the repository. This new working
tree is called a "linked working tree" as opposed to the "main working
tree" prepared by "git init" or "git clone". A repository has one main
working tree (if it’s not a bare repository) and zero or more linked
working trees.

A complete copy here: https://git-scm.com/docs/git-worktree

silvio
  • 121
  • 3