DTAP Using Workbench with Git

There are a number of ways developers can agree to implement DTAP for source control when using Workbench. Basically, programmers have a working copy of the code that they update, test, and commit locally. Once they are ready to share the code, they push it to the central repository where it is available to other developers to pull and merge those updates to their local working copies. This is all part of "development".

Beyond local working copies, the final code changes pushed to the central repository can be pushed and pulled as needed on different testing and acceptance servers. In general, pulling to the production server is done once when all updates are finalized. Generally there is no plan to push from the production environment back to the central repository.

In Workbench, a project holds both the working copy of the code files, as well as the local Git repository. The different developer projects can be defined on the same server using different directories, on different servers, on the same DiveLine using different project names, or on different DiveLines with different port numbers. Developers should discuss and agree upon a scheme that supports their needs.

For the central repository, there are also multiple options. The central repository can be located on the same machine as the working copies, on a different machine on the network, in shared disk space, or in the cloud.

More ideas for working with version control can be found here: https://git-scm.com/about/distributed

There are two ways to clone a repository in Workbench, one of which involves creating a new Workbench project and one of which clones the repository to an existing Workbench project: