Skip to main content
Git is a tool used for source control management in software development. It helps developers keep track of changes made to a project’s source code, and collaborate without overwriting each other’s work. Designer is built with Git from the ground up for version control, making it simple to collaborate and manage your data pipelines within your team. For a fuller explanation of what Git is and why it exists, read What is Git? from the official Git documentation.

​
Features

Git in Designer offers you:
  • Version control: Git keeps a history of every commit, allowing developers to view and track progress in a project.
  • Collaboration: Multiple developers can work on the same project simultaneously. Git tracks each person’s changes separately, so they can be pulled together and merged without overwriting each other’s work.
  • Branching and merging: Git makes it easy to create new branches for experimenting with new features, or for fixing bugs. You can then merge those branches back into the main codebase.
  • A distributed system: Git is a distributed version control system, which means that each developer has their own full copy of the repository, including its entire history—not just the current branch. This makes it easy to work in isolation and merge changes back into the main codebase later. See the note below for how this works in Designer.
It’s important to note the difference between how Git works in Designer and standard Git. When you work in Designer, you don’t have a copy of the files in your local machine. Instead, you’ll have an online copy of the remote repository. This is essentially your working directory, which you can access when you’re logged into Maia with this specific account. However, the online copy in Designer is not automatically synced to the remote repository; therefore, changes that are staged and committed are isolated from the remote repository until you push. In the same way, new changes that are pushed to the remote repository by others are isolated from your online copy in Designer, until you pull remote changes.

​
Repositories

When using Maia, you can either choose to use a Maia-hosted Git repository, or to connect your own Git repository to Maia. To use a Maia-hosted Git repository, create a project and select one of the following options. When you create a project in one of these ways, an associated Maia-hosted Git repository is created, containing a default branch called main.
  • Choose a Maia managed project.
  • Choose Advanced settings to configure your own project setting, then select Maia Hosted Git.
To use an external Git provider, you need to connect your own Git repository to Maia. The external providers that are currently able to be connected to Maia are GitHub, Azure DevOps, GitLab, and Bitbucket. For more information, read Connect your own Git repo.
Once you connect a project to a Git repository (GitHub, GitLab, Azure DevOps, or Bitbucket), you cannot disconnect or change the Git repository connection.You must create a new project from scratch if you need to:
  • Disconnect from your current Git repository.
  • Connect to a different Git repository.
  • Switch between different repo host platforms (e.g., from GitHub to GitLab).
Reusing an existing Matillion ETL Git repository isn’t supported and can cause issues with your pipelines.
We recommend using branches other than main (or the equivalent branch in your own Git repository) to develop your orchestration and transformation pipelines. For more information about creating and managing branches, read Branches.
Maia context files allow you to define project specific standards, naming conventions, and guidance that Maia uses to generate consistent pipelines. To ensure these files are properly shared across branches, follow the recommended Git workflow. Read View Git workflow for managing context files.
To start creating orchestration and transformation pipelines, open your project and click the branch you want to check out. You will then be redirected to the Designer UI.

​
Git actions

You can find the available Git actions by clicking the name of your branch on the project bar. This opens a drop-down menu containing all available Git actions.
  • Commit changes to your pipelines, creating a new snapshot of the code. A commit is a “local” action and should be followed by a push action when you are ready to collaborate.
  • Push local changes in your commits to the remote repository when you’re ready to collaborate, allowing other team members to access (pull) the changes into their own copy of the remote.
  • Pull remote changes from remote to your copy of the branch, updating your working directory version of the code.
  • Merge from branch to integrate changes from another branch—either its remote or local copy—into your local branch. To see someone else’s merged changes, you will need to pull from remote. Use this action to resolve merge conflicts between your branch and the branch you are merging from.
  • Compare changes to compare the local changes you have made in a file to the version of that file from the last commit.
  • Revert changes to revert the state of your branch to a previous commit.
  • Reset branch to reset your local branch to either of the following states:
    • Reset to the latest local commit, discarding any uncommitted changes in your local branch.
    • Reset to the latest remote commit, discarding any local commits and any uncommitted changes in your local branch, and then pulling the latest commits from the remote branch.
  • View pull requests to see the pull requests you have created in your Git repository.
  • View commit history to view all the commits you have made in your current branch.