Understand Git Workflow in biGENIUS-X

The biGENIUS application uses Git to manage versioning.

This versioning management is available on the Branch overview page.

The Git Workflow usage has been streamlined and integrated into biGENIUS-X to prevent confusion.

In this article, we will explain which actions are possible with Git and how we handle them in biGENIUS-X.

What is Git

Git is the version control chosen by the biGENIUS application to manage project versions.

Git is a Distributed Version Control System. Git does not rely on a central server to store all the versions of a project’s files.

In biGENIUS-X, every user clones a copy of the project in the Web browser cache and has the project's entire history on their Web browser.

This clone has all of the original's metadata, while the original is stored on a self-hosted server or a third-party hosting service such as Azure DevOps, GitHub, GitLab, or BitBucket.

There are several Git workflows: Basic, Feature Branches, Gitflow, Feature Branches and Merge Requests, and Forking workflow.

The Feature Branches Git workflow is used In biGENIUS-X with, in addition to the standard, the management of hotfixes.

Branches concept

In Git, a Repository can contain several Branches.

In biGENIUS-X, we differentiate between 4 types of Branches, local or remote branches.

• Feature Branch: 
  • Short-lived
  • Create a new Feature Branch before start modeling in a Project
  • Once the changes are merged into the Main Branch, the Feature Branches should be deleted
• Release Branch: 
  • Long-lived
  • Cannot be modified (except for hotfixes)
  • Correspond to a Project state used in Production
• Hotfix Branch:
  • Short-lived
  • To apply a hotfix on a Release Branch

• Main Branch: 
  
  • Forever-lived (except if you delete your Project)
  • Store the official releases/features history

Git standard Workflow

In a typical Git Workflow, there are four core components:

• Working Directory: current state of the Git directory: new files that are not yet tracked and files modified since the last version.
• Staging Area: the intermediate zone between the working directory and the Repository. It contains the changes made in the working directory that Git will add to the Repository during the next commit.
• Local Repository: working local copy of a remote repository. 
• Remote Repository: files stored remotely in Azure DevOps, GitHub, or GitLab.

In biGENIUS-X, we simplify the components and only manage branches in the:

• Local Repository (stored in the Web browser cache)
• Remote Repository (stored in Azure DevOps, GitHub, or GitLab)

Git actions

The following actions are possible with Git:

• Git branch: create a new Branch. To start modeling, you create a new Branch of the main Branch using git branch new_branch. Once created, you can use git checkout new_branch to switch to this Branch.
• Git commit: add all files that are staged to the local Repository.
• Git push: add all committed files in the local Repository to the remote Repository. So, in the remote Repository, all files and changes will be visible to anyone with access to the remote Repository.
• Git fetch: get files from the remote Repository to the local Repository but not into the working directory. The files are stored locally but not merged with your current state.
• Git merge: get the files from the local Repository into the working directory.
• Git pull: directly get files from the remote Repository into the working directory. It is equivalent to a git fetch and a git merge.

Git Workflow in biGENIUS

As mentioned, the Git Workflow usage was simplified in biGENIUS-X to avoid confusion.

This is the workflow in place:

In biGENIUS-X, you can interact with Git with the following features:

• Create a Feature: create a new local repository (Branch) with a copy of the file stored in the Main Remote Repository
• Push: execute a git commit + git push. Copy the local changes from the local Branch to the remote Branch.

• Pull: execute a git fetch + git merge. Copy the remote changes from the remote Branch into the local Branch and merge the files if necessary.
• Fetch: Copy the remote changes from the remote Branch into the local Branch, but don't do any merge.
• Checkout: create a local Branch from a remote Branch.