SVN uses a single centralized repository as a communication interface for developers, with collaboration taking place via changesets. The changesets are exchanged between the developers' working copies and the central repository. This is the most important difference to the distributed collaboration model of Git, where each developer receives their own copy of the repository with their own local history and branch structure. This allows entire branches (rather than a series of consecutive commits or individual changesets) to be shared between repositories. The "Git Remote" command is part of a broad system for synchronizing changes. With "Git Remote" a connection to other repositories can be created, retrieved or deleted. Entries via "Git Remote" are used together with the "Git Fetch", "Git Push" and "Git Pull" commands. The "Git Fetch" command downloads commits, files and references from a remote repository to the local repository to see what everyone else is working on. By viewing progress in the central history with no impact on local development work. The retrieved content must be explicitly checked out with the "Git Checkout" command to safely review commits before integrating them into local repositories. The "Git Push" command is used to upload content from a local repository to a remote repository. You use the "Git Push" command to transfer commits from your local repository to a remote repository. The counterpart to this is the "Git Fetch" command, which imports commits into local branches. You can use "Git Push" to export commits to remote branches. Remote branches are configured with the "Git Remote" command. As there is a risk of overwriting changes when pushing with "Git Push", you should be careful. The "Git Pull" command is required to download content from a remote repository. This will immediately update the local repository so that the content matches. Merging upstream changes with your local repository is often required in Git-based collaboration workflows. The "Git Pull" command is actually a command combination of "Git Fetch" followed by "Git Merge". "Git Pull" first performs a "Git Fetch" that includes the local branch and points to the HEAD. As soon as the content has been downloaded, "Git Pull" starts a merge workflow. A new merge commit is created and HEAD is updated to point to the new commit. These and other Git commands and Git tools can be learned in a Git course.

TortoiseGit or "Git Tortoise" is a free graphical user interface for the version management software Git under Windows. It is licensed under the General Public License (GNU). "Git Tortoise" is implemented as a shell extension and is integrated into Windows Explorer. It can be used independently of an integrated development environment. Icons represent the respective status such as versioned, unchanged, modified or ignored. The main interaction takes place via the context menu. Various actions are executed there with commit, push or pull and TortoiseGit dialogs are opened. The software has version, revision and source control as its core tasks. Technically, "Git Tortoise" is based on TortoiseSVN - enhanced with Git-specific aspects.

Git Lab is a version control system (VCS) based on Git. Git focuses on saving file versions and is the most widely used versioning system in the form of open source software. GitLab, on the other hand, is used by developers and programmers to work agilely and efficiently on software and web projects. It is hosted on your own server. Daily work is made easier by the fact that several programmers can develop at the same time and work on different features. This is because continuous versioning ensures that all changes are logged. This means that no work is lost or accidentally overwritten. Changes made to the code are monitored and can be undone if necessary. Created projects are organized in digital archives called repositories. A repository contains all the components of a project, including the associated PHP, JavaScript, HTML and CSS files. By checking out, project participants load a working copy of a repository onto their computer and the changed version is checked back in after editing. GitLab is based on an open core business model that is available in two license models: GitLab Community Edition (CE) and GitLab Enterprise Edition (EE).

GitHub is a network-based version management service for software development projects. This collaborative version management runs on the Git version management system. But what is Git vs GitHub? Git ensures that different files are saved as versions during different phases of a project. GitHub, on the other hand, is a cloud-based repository that shows edits and changes in real time. In contrast to other open source software service providers, GitHub is not centrally concerned with the project as a collection of source code, but with the user and their source code databases - also known as repositories. The creation (GitHub branch) and merging (GitHub merge) of forks is also important. This makes it particularly easy to co-develop third-party projects, as changes can be forked and made via the source code databases. These changes are only adopted later. As all steps are also possible via the web interface and there is a social network with access to repositories of others as well as a smartphone app, GitHub is also suitable for beginners as a developer platform. The platform has been part of Microsoft since 2018. GitHub is larger than GitLab, for example, and is trusted for its longevity and more developers are working on the platform extension, resulting in a very stable, high-performance system.

The GitLab CI server - also known as the coordinator - does not execute any builds itself. It delegates this to so-called runners. A runner is a process that polls the coordinator to pick up and process pending jobs. The principle of GitLab CD is referred to as a GitLab pipeline. This GitLab pipeline defines under which condition which validation is checked in order to publish the corresponding software parts. Code versioning and associated techniques such as branching play an important role in CD.
GitLab can be used as a web-based application or can be installed on your own server (GitLab self-hosted). GitLab Pages can be used to host static websites and create project documentation.

A GitLab tutorial includes the following content:

• Create users in GitLab via "New User"
• Create a new project with "New Project"
• Working together in a team with GitLab with authorizations and access rights

Knowledge about GitLab can also be acquired with a Git course.

When working in Git, "save" is more nuanced than in a word processing program and includes a collection of files and directories. Save is a synonym for the Git term "commit" - for save it is "commit". The Git command "Git Commit" can be used to capture a snapshot of the currently deployed changes to the project. Such committee snapshots are considered safe versions, as Git only makes changes on explicit instruction. Before the "Git Commit" command, the "Git Add" command is required to save changes in a commit, to promote them to the project in the staging environment or to "stage" them. As a result, the Git commands "Git Commit" in combination with the "Git Add" command are among the most frequently used and form the basic Git workflow. This is followed by the "Git Status" command to retrieve the status of the working directory and the staging environment. The "Git Stash" command, on the other hand, causes changes to the working copy to be temporarily postponed (or stashed). This allows the programmer to focus on other tasks and apply the changes later. This is practical if the programmer is in the middle of a code change, is not yet ready to commit and needs to quickly continue working on something completely different.

A short Git tutorial explains how Git works:

• Create a "repository" project with a Git hosting tool such as Bitbucket
• copy or clone the repository to your local system
• add a file to the local repository and perform a "commit" for the changes to "save"
• Move changes to your master branch via "Push"
• make a change to the file with a Git hosting tool and commit it
• perform a "pull" to apply the changes to your local system
• create a "Git branch" (a Git version), make a change and commit it
• Open a "pull request" (change proposals for the master branch)
• perform a "merge" of the changes in the master branch

Git introduction, Git commands and installing Git are taught in a Git course.