Push and Pull Commit
Committing sends your changes to the branch in Git. Pulling brings changes from Git back into ToolJet.
Commit Changes​
The default branch is read-only, so you commit from a feature branch and the changes reach the default branch through a merged pull request.
To commit datasource changes:
- Go to the Data sources page on a feature branch.
- Click Commit in the header.
- Enter a commit message.
- Click to commit and push.
To commit application or module changes, open the application in the App Builder or the module in the Module Builder and use the GitSync button in the header.
That button changes with the branch you are on and whether the resource has reached Git yet:
| Button | What it does | When it appears |
|---|---|---|
| Commit | Commits the resource to the current branch | On a feature branch |
| Pull commit | Pulls changes from Git into the resource | On the default branch |
| Sync | Opens the first-time push flow | On the default branch, for a resource never pushed to Git |
| Configure Git | Opens the GitSync configuration | When GitSync is not yet configured for the workspace |
It is shown in the Development environment while a draft version is selected. Saved and released versions are read-only and offer no Git action. Sync is the exception: it stays visible in every environment and on any version until the resource is pushed for the first time.
Before committing, ToolJet checks that your branch still exists in Git. If it was deleted remotely, the commit is blocked and you need to create a new branch to continue.
Commit only re-pushes resources that Git already knows about. A resource that has never been committed is handled by a separate first-time push flow, see Push Unsynced Resources to Git.
Scope of a Push​
A push always covers the resource you are pushing plus the resources it needs to run. Unlike pulling, there is no dashboard action that pushes a whole branch at once, so each application, module, or set of datasource changes is pushed from its own screen.
| Where you push from | What is pushed |
|---|---|
| App Builder | The application, plus the modules and datasources it depends on |
| Module Builder | The module, plus the resources it depends on |
| Data sources page | Datasource changes on the current branch |
Dependent resources travel with the resource so it does not arrive in Git in a broken state.
What Is Committed​
Applications, modules, datasources and folder assignments are written to Git. Datasource credentials are treated carefully, so connecting the same repository to several instances does not move secrets between them.
| Value | Written to Git |
|---|---|
| Non-encrypted datasource options, such as a host or port | Yes |
| An encrypted field backed by a workspace constant | The reference only, for example {{constants.db_password}} |
| An encrypted field with a value typed directly | No |
| Runtime authentication artifacts, such as OAuth tokens | No |
Pulling follows the same rule in reverse. A workspace constant reference from Git updates the local value, non-encrypted values from Git overwrite local ones, and a directly entered credential is never overwritten by a pull.
Use workspace constants for credentials you want to travel with the repository. Constants are resolved per environment, so the same reference points at the development value on one instance and the production value on another. Anything typed directly into a datasource field stays on the instance where it was entered, so each instance keeps its own credentials and must have them set once.
Pull Changes​
The Pull button is available on every branch, including the default branch.
Scope of a Pull​
What a pull brings in depends on where you start it:
| Where you pull from | What is pulled |
|---|---|
| Dashboard header, on the Applications, Data sources, or Modules page | The whole branch: every application, module, datasource, and folder assignment |
| App Builder, using the GitSync action in the header | Only that application, plus the modules and datasources it needs to run |
| Module Builder, using the same GitSync action | Only that module, plus the resources it needs to run |
Pulling from a builder leaves the rest of the branch untouched, which is what you want when only one application is ready to test or release. Pull from the dashboard when you want the branch brought in as a whole, for example when setting up a fresh instance.
What you can choose also depends on the branch:
- On the default branch, you choose between the latest commit and a specific saved version.
- On a feature branch, there is nothing to choose. The latest commit on that branch is pulled.
Pull From the Dashboard​
- Click Pull in the header.
- Confirm the branch to pull into.
- Confirm the pull.
Pulling a whole branch runs as a background job and notifies you when it finishes. Applications, folders, and datasources update automatically once the job completes.
On the default branch, pulling removes applications and modules that are no longer present in Git, and deactivates datasources that are no longer present. On feature branches, these resources are preserved.
Pull a Saved Version​
Every saved version is tagged in the Git repository at the point it is saved. Pulling a version restores it from that tag and recreates it in the workspace as a published version. Refer to Version Control with Git for how drafts, saved versions, and Git tags relate to each other.
Saved versions can be pulled for the following use cases:
- Application migration - Move a version from one instance to another, such as development to staging or production, without exporting and importing it.
- Version recovery - Restore a version that was deleted from the workspace.
Saved versions exist only on the default branch, and they are pulled from inside the application rather than from the dashboard. There are two ways to do it.
From the Version Dropdown​
Use this to see which versions exist in Git but not yet in this workspace, and bring one in on its own.
- Open the application on the default branch and open the version dropdown in the header.
- Click Refresh. ToolJet checks Git for versions of this application.
- Any version that exists in Git but not in this workspace is added to the list.
- Hover that version and click Pull.
Versions are listed per environment, so switch the Development, Staging, and Production tabs to see the versions available in each.
From the Pull Commit Dialog​
Use this when you want to choose between the latest commit and a saved version in one place.
- Open the application on the default branch.
- Click Pull commit in the App Builder header.
- Choose a version from the Version list, or keep Latest commit to pull the newest changes instead.
- Confirm the pull.
A version that already exists in the workspace is not pulled again.
Pulling a saved version does not affect the current draft, which continues to track the latest commit on the branch.
Conflicts​
If ToolJet detects duplicate names or slugs between your workspace and the incoming changes, the operation stops before making any changes and opens a conflict dialog. Nothing is written until the conflicts are resolved.
See Resolving Conflicts for the categories and how to fix each one.
Need Help?​
- Reach out via our Slack Community
- Or email us at support@tooljet.com
- Found a bug? Please report it via GitHub Issues