Development Source Control

A JADE environment and its development environment sit in a larger development ecosystem, which can consist of other development tools, testing frameworks, test systems, and so on. These are often tied together with a version control system (VCS), which uses and supports one or more different workflows, even if the overall development goal is the same.

JADE incorporates a Git client, so that you can use an on‑premises or a cloud‑based Git provider to move your source and source changes into (push) and out of (pull) your team's source repository, to more‑easily incorporate your JADE source into a modern development workflow.

The JADE Git client functionality is fully compatible with other Git clients.

The JADE product information library documents only the JADE implementation of the Git source control; it does not cover the Git technology itself. (If you are not familiar with Git, see https://git-scm.com/book/en/v2.)

A Git client runs on either a presentation client or a standard client. The working directory can be anywhere on the network; it is not restricted to your local file system.

To use the Git client functionality, your Git administrator or team leader would normally create a bare Git repository on a server for the team. For details, see https://git-scm.com/docs/git-init.

JADE forms definition files are optionally encoded in Extensible Markup Language (XML) format as .ddx files.

The Source Control feature comprises mainly an integrated Git client working on files extracted to or loaded from the Git working directory, using the Browse menu Git Source Control Client command and its submenu commands.

To commit one or more changes in Git, you do not have to be online or connected to the remote repository, because you have a full repository on your local file system. Commits are therefore recorded only in your local repository and they are not transferred to the remote repository until you explicitly decide to share them.

When you modify a file, it is not automatically included in the next commit. You must explicitly mark the changes you want included in the next commit, by adding them to the staging area. You can stage complete files only. A hashed string (a string directly generated based on the information it represents) is used instead of an ascending revision number, so that commits in Git are uniquely identified.

As Git is a distributed version control system (DVCS), rather than relying on a central server to store development history, the complete version history is recorded in a local copy, or clone, of a remote repository. This allows you to:

Maintain your own history of changes, independent of any other copy, extract your changes, and publish them to a more-central repository only when you are ready to do so
Develop your source without needing to access a central server at all times during the development process

A Git clone returns a full-fledged repository; not just a working copy. You then have your own repository on your local machine, including the complete history of the project. You can do everything on your local machine; for example, commit, inspect history, restore older revisions, and so on. Only when you want to share your work with a wider group do you need to connect to a remote server.

The JADE development environment provides source control security hooks. The Git client repository requires authentication and authorization. For details, see "Source Control Functions", in Chapter 2 of the JADE Object Manager Guide.

The Source Management sheet of the Preferences dialog enables you to define your own Git client options; that is:

Your Git user name, which is used to identify you as the author for a Git commit operation.
Your e-mail address, which also identifies you as the author for a Git commit operation.
Your working (local) directory.

For details, see "Maintaining Source Management Options", later in this chapter.

A typical development cycle iterates over the following steps on your workstation.

Add or maintain your JADE changes (for example, classes, methods, or properties).
Extract each change (singly, selectively, or as a schema) to your local Git folder.
Stage and commit your change or changes to your local repository.
Merge your changes.
Push your changes to the remote repository.

The Git Source Control Client submenu in the Browse menu provides commands that enable you to configure your source control client, to clone a remote repository, to check out a source control branch or tag, to commit changes to your local repository, and to push and pull source changes to and from the remote repository. For details, see:

2018.0.01 and higher

For details about source control authentication, see "Source Control Authentication", in the following section.