Git Integration

📘

Before You Start

This article assumes you've already connected your organization's git repository. If you still need to do so, you can find instructions in our Git Settings article.

Coalesce leverages git version control, which can be accessed once connected with your remote git repository. All relevant metadata you create in your development environment gets converted into YAML files that are versioned and available for pipeline deployments. The YAML files include metadata for defined nodes, subgraphs, jobs, macros, node types, and storage locations.

Accessing Version Control

Within the Build tab of the application, click the git branch button in the bottom left, pictured below.

Location of version control in **Build** tabLocation of version control in **Build** tab

Location of version control in Build tab

Once the Version Control Window is open, you'll be presented with the commit staging area:

The list on the left denotes the changes in your workspace since the last commit in your current branch. The colors next to the file names refer to the type of change.

  • Green: New file
  • Orange: Modified file
  • Red: Deleted file

Viewing File Differences

There may be one or many files to review on the left side. To view changes to a specific file, click on it, and the two panes on the right will populate with the file's previous state in the left pane and its current state in the right pane. Scrolling through the file will show you patches of green and red, which denote where additions and deletions have occurred.

Example of a replacement, where a LOWER() transform was applied to C_MKTSEGMENT.  The C_COMMENT column was deleted without replacement.Example of a replacement, where a LOWER() transform was applied to C_MKTSEGMENT.  The C_COMMENT column was deleted without replacement.

Example of a replacement, where a LOWER() transform was applied to C_MKTSEGMENT. The C_COMMENT column was deleted without replacement.

Viewing these differences allows you to understand better what has changed between now and your last commit for these files.

Using Version Control

By default, when opening the Version Control window, all files will be added to the commit unless you take explicit action to switch the toggle next to the files you wish not to include. If there is work done on a file that you are unsure is ready for a commit, you should reach out and collaborate with your team to ensure you aren't committing a work in progress.

To make a commit, have at least one file toggled for addition and write a short descriptive message of the work encompassed by the commit in the Commit Message text box as seen below.

Example commit message before pushing to remote repositoryExample commit message before pushing to remote repository

Example commit message before pushing to remote repository

To save the commit to the remote repository, click the Commit and Push button in the bottom right corner of the Version Control Window.

You will then see a series of messages in the bottom and top left corner that will either finish with a success message seen below or a description of what went wrong.

Version Control Window after a successful pushVersion Control Window after a successful push

Version Control Window after a successful push

If you have no more changes to display, the list on the left will reflect that, as seen in the picture above. However, if you didn't commit all files, the list will reduce to show just those files. This will allow you to make multiple commits within one use of the Version Control Window, following the same process outlined above.

Making a New Branch

By default, you'll be on your project's default branch, which you can see along with its commits by clicking on Branches from the Version Control Window.

`main` branch with only a few **Source Nodes** committed`main` branch with only a few **Source Nodes** committed

main branch with only a few Source Nodes committed

To make a new branch, click on the Branch icon on an existing commit, type in a name for it, and a new branch will be created from the current one. In this example, there's a new branch called stage_nodes where I'll shortly be adding a few Stage Nodes.

On `stage_nodes` branch.  Notice it looks identical to `main`, as it was forked from it and no additional changes have been committed yet.On `stage_nodes` branch.  Notice it looks identical to `main`, as it was forked from it and no additional changes have been committed yet.

On stage_nodes branch. Notice it looks identical to main, as it was forked from it and no additional changes have been committed yet.

Checking out Branches

When you create a new branch, you will automatically check it out, but if you'd like to return to another branch, you can do so by selecting the branch from the dropdown and clicking Check Out Latest.

Selecting a branchSelecting a branch

Selecting a branch

If you haven't committed your latest changes on your current branch, you will receive a warning message that checking out another branch could cause you to lose those changes. If you'd like to force the checkout, click on the three dots next to Check Out Latest and select Force Checkout.

❗️

Force Checkout

Ensure you know what you're doing before a forced checkout, as there's no reverting of uncommitted changes once a forced checkout is complete.

Merging Branches

After making changes and making a commit to a branch, you can merge the changes back to another branch.

  1. Check out your destination branch to make it your Current Branch
  2. Select the source branch with the incoming changes from the Selected Branch dropdown.
Notice that Current Branch is `main`, Selected Branch is `stage_nodes`Notice that Current Branch is `main`, Selected Branch is `stage_nodes`

Notice that Current Branch is main, Selected Branch is stage_nodes

  1. Click on Merge Latest or Merge next to the desired commit you would like to merge into the current branch.

All the changes from Selected Branch will be merged into your Current Branch.

Handling Merge Conflicts

There will be times when two branches or commits can't be merged, as they have conflicting data. Let's go through a simple example to illustrate this.

On my main branch, I have a transform in my STG_CUSTOMER node to LOWER() the C_NAME column. On my stage_nodes I've done the same, except this time I'm using UPPER() instead. These are mutually exclusive changes, and attempting to merge the stage_nodes branch into main will result in a conflict.

Example of a merge conflictExample of a merge conflict

Example of a merge conflict

📘

Tip: Searching for Merge Conflicts

You can use your operating system's search functionality within the Merge Conflict Window by clicking CTRL + F or Command + F once your cursor is in the text box.

To resolve the merge conflict(s), remove the conflicting code lines and all conflict markers. See the screenshot below for an example.

Decided to keep LOWER(), so deleted the markers as well as the UPPER() transformDecided to keep LOWER(), so deleted the markers as well as the UPPER() transform

Decided to keep LOWER(), so deleted the markers as well as the UPPER() transform

Note that there will be rare situations where a merge conflict will be too complex to resolve within Coalesce and require going through the git provider's platform (ex GitHub) to resolve before merging the branches/commits. Our system will make you aware if this is the case and warn you accordingly. If you have a use case where you're running into this situation often, please reach out to our Support team.


Did this page help you?