CODEWITHSUNDEEP
git
Andrew
Andrew

Reputation: 3

GIT multiple concurrent development version question (NOT GitHub)

Firstly, we are very new to GIT.

Here is the workflow (no source management software at all):

        Live Version
              |
   /----------|----------|----------|----------\
   |          |          |          |          |
   |       DevVer1    DevVer2    DevVer3    DevVer4
   |          |          |          |
   |       TestVer1   TestVer2   TestVer3
   |          |          |          |
   |----------/          |          |
   |---------------------/          |
   |--------------------------------/
   |
   ...

At first glance this may seem like a standard cycle, however, we have not been able to get GIT to handle this nicely. Let's say DevVer1/2/4 are checked out by Dev1 and DevVer3 is checked out by Dev2. DevVer1/2/4 are in separate folders (and obviously so is DevVer3). All 4 of the DevVers are based on the same version. All 4 are worked on concurrently. All 3 TestVers are tested concurrently. DevVer4 could become a TestVer at any time. Any of the TestVers could be made live at any time in any order. Whichever version is made live - it is then manually merged into the outstanding dev versions etc.

We cannot get GIT to play nicely with this method. We tried worktree but we couldn't get it to work. It is entirely possible we are going about it incorrectly.

Is there a SIMPLE way of achieving the above?

Thanks in advance.

Upvotes: 0

Views: 139

Answers (1)

IMSoP
IMSoP

Reputation: 97978

I think your problem is this:

DevVer1/2/4 are in separate folders (and obviously so is DevVer3)

You may not have had any source management software before, but you had a source management system: you defined a series of versions, and you used a tool to separate those versions. The tool you used was a file system, and the facility a file system offers is directories, so you mapped versions onto directories, because that was the only option you had. "When all you have is a hammer, everything looks like a nail."

Some version control software (e.g. Subversion) is based on a sort of extended file system, and you can carry this thinking across. Git is not.

Git is a database of immutable versions of a project, each identified by a hash of their content, and arranged into a graph by each one pointing to one or more previous versions. To give names to versions, it has branches (and tags, but those aren't relevant right now) which point at a particular version.

Branches are your new hammer. Every one of the text labels on your diagram can be represented as a branch. You can develop them, test them, and merge them, in all the ways you describe.

The one thing you have to give up on is the idea that a particular directory on your file system corresponds to a particular version. You might still have multiple directories, each of which is a "clone" in git's terminology, but one will be "whatever Bob is working on right now", one will be "whatever Jane is testing right now", and so on. Maybe one will always be "whatever is currently on the live branch", so you can do quick comparisons. Sometimes, multiple directories will point at the same branch (e.g. one person testing it, another person debugging a fix to the last bug they found, without interrupting the testing), while other branches aren't checked out anywhere (nobody's working on DevVer3 right now? that's fine, it's all in git's database).

You may also find that, with the extra power a version control system gives you, you want to change which branches you use. Once you get to that stage, there's a lot of writing out there on different "branch strategies" or "workflows" - "git flow", "github flow", "trunk-based development", and so on.

One last important point is that the actual live code should not be a git clone at all - git is not a deployment tool. You should take a particular version of the code (usually a tag, which is just a branch that doesn't change), and deploy it to a live server. The "live code" branch is just "where the live code came from".

Upvotes: 3

Related Questions