5) Transferring changes to the central development state

From the file system to the repository (via VCS)

In this step, the version control system is used to

• transfer the development state from the local file system (from the Sync directory) into the local repository.
• transfer the development state from the local repository into the remote repository.

See figure Step 5) Commit/Push.

Initial situation

Preparation

The developer’s local repository has already been updated using the version control system (see 1) Update). During this process, the central development state was transferred out of the remote repository. The project content and, if applicable, project properties are in the Sync directory (file system) and ready for import.

Before further development, all content is imported into the local FirstSpirit project instance (see 2) Import).

The project content is then edited (see 3) Modification). Once a stable state has been achieved after editing is complete, the modified development state from the local FirstSpirit project instance is ready for export.

The local development state has been completely exported into the Sync directory (in the local file system) (see 4) Export). The changes can now be transferred to the repository and therefore into the central development state.

Confirming and uploading changes

For successful collaboration, the (further) development must always be carried out in the most current state possible; in other words, the local modifications made by all developers in the team must be transferred to the central development state as soon as possible. Changes are merged via the version control system.

For this process, the changes in the local repository have to be confirmed at regular intervals (e.g., in Git via commit) and then loaded into the remote repository (e.g., in Git via push).

The changes are then available to all developers during an update (see figure “fetch”/“checkout”).

Confirming changes (commit)

All of the changes are in the developer’s local target directory. From there, the developer transfers the changes into the (local) repository, e.g., via git commit. The changes are then included in the local repository (but not in the remote repository yet).

If the contents have been changed in the file system, an import into the project and then an export into the file system must always be carried out before the final git commit or before transferring them into the central development state – only then can the changes be transferred into the central development state (see Responding to external changes).

Uploading changes (push)

Changes are then sent out from the local repository to the remote repository, e.g., via git push. This makes local changes “public” and ensures they are visible for other developers.

At this level, changes made by all developers involved are merged via the VCS. Conflicts – overlapping changes – are dealt with and rectified in an automatic process wherever possible.

Next steps

Once the changes have been transferred to the central development state (into the remote repository), the editing process is complete for the time being. Changes are now available to all developers involved.

Before starting any work on a (new) work package, the local repository has to be updated again. This ensures that changes made by other developers are transferred into your own local development environment. The editing cycle starts again.

Continue with Step 1) Update.