Links your repositories to your projects. Issues and tasks stay in step in the direction you choose, comments flow both ways without looping, and webhooks keep it current. From a work item you can create a branch and open a pull request, and pipeline results from GitHub, GitLab, Bitbucket, and Jenkins are recorded against the work item they belong to. A pull request can be gated on the status of the task it is for.
- Installs
- Available
- Support
- Vendor Supported
- Trust
- Self-Hosted
Active deployments
Priority response
Your infra, your data
Screenshots
Key Features
Three Providers
GitHub, GitLab including a self-hosted instance at your own base URL, and Bitbucket. Each is connected with OAuth2 and each speaks through the same internal interface.
Encrypted Credentials
Provider client secrets and access tokens are encrypted at rest with the application security salt rather than sitting in the database in the clear.
Two Way Issue Sync
Map a repository to a project and choose one way or two way. Field mapping and state translation keep an issue and a task describing the same thing in both places.
Comment Sync Without Loops
Comments travel in both directions with sync markers, so a comment that came from the provider is not immediately sent back to it as a new one.
Webhooks
One endpoint receives issue, pull request, comment, and push events. The provider is identified from the request headers, and payloads are verified before anything is acted on.
Polling Fallback
A cron command runs the same sync for every enabled synchronisation, which is what you need when the server sits on a private network that no provider can call.
Branch From a Work Item
Create a branch for a task on GitHub, GitLab, or Bitbucket with a computed name, and the link back to the work item is recorded when it is created.
Pull Request From a Work Item
Open a pull request on GitHub or a merge request on GitLab straight from the task, already linked to the work item it belongs to.
Work Item Linking
Push and pull request events are resolved to work items by the task references in the branch or the payload, within the project mapped to that repository.
CI Runs Recorded
Pipeline and build events are normalised and stored against the work item, matched by the branch reference or the head commit, so a red build is visible on the task.
Jenkins Support
Jenkins reports build status and can have jobs triggered. It has no issues, pull requests, or branches, so it takes part in the CI surface rather than the sync surface.
Pull Request Gating
Decide whether a pull request may proceed based on the status of the work item it is for, and write the verdict back as a commit status the provider's own required check honours.
Dry Run Without a Token
Branch creation, pull request creation, gating, and Jenkins calls all return the request they would have sent when no token is stored, so you can wire the flow up before granting access.
DevOps Settings Per Project
Settings resolve per project with a company wide fallback, so one repository heavy project can behave differently from the rest without a separate install.
Sync History
Every synchronisation run is logged, so when a task and an issue disagree you can see what ran, when, and what it did rather than guessing.
Manual Sync and Toggle
Run a synchronisation on demand, or switch one off without deleting it and losing the mapping you configured.
About this plugin
Why Git Sync for Orangescrum?
Delivery teams live in two systems and pay for it in copying. A task exists in the tracker and an issue exists in the repository, and keeping them in step is somebody's unpaid job. This add-on connects the two so the branch, the pull request, and the build result all show up against the task, and the task status is visible to the people reviewing the code.
Three providers, one model
GitHub, GitLab, and Bitbucket connect over OAuth2 and speak through a single internal interface, so repositories, issues, comments, webhooks, and labels behave the same way whichever one you use. GitLab can point at a self-hosted instance on your own base URL, which matters when the whole reason you run Orangescrum self-hosted is that nothing leaves your network. Client secrets and tokens are encrypted at rest.
Sync that does not fight itself
Map a repository to a project, choose one way or two way, and set the field mapping. Comments travel in both directions with sync markers, so a comment that arrived from the provider is not sent straight back as a new one. Webhooks keep it current, and where webhooks cannot reach a private network a cron command runs the same sync on a schedule instead.
Start the work from the work item
From a task you can create a branch on any of the three providers and open a pull request on GitHub or a merge request on GitLab, already linked to the item it belongs to. Push and pull request events are resolved back to work items by the task references they carry, within the project that repository is mapped to, so the link survives even when somebody creates the branch by hand.
Build results where the work is
Pipeline and build events from GitHub, GitLab, Bitbucket, and Jenkins are normalised into one shape and recorded against the work item, matched by branch reference or head commit. A failing build stops being something only the person who pushed it notices. Jenkins is a CI participant rather than a sync participant, because it has no issues, pull requests, or branches to sync.
Gate the merge on the work, not the memory
A pull request can be gated on the status of the work item it is for, with the verdict written back as a commit status that the provider's own required status check then honours. Because branch creation, pull request creation, gating, and Jenkins calls all run as a dry run when no token is stored, you can wire the whole flow up and see the requests it would send before granting anything real access.
What's included
- OAuth2 connections to GitHub, GitLab, and Bitbucket
- GitLab self-hosted support through a configurable base URL
- Encrypted storage of provider client secrets and access tokens
- Repository listing and repository to project mapping
- One way and two way issue synchronisation with field mapping and state translation
- Bidirectional comment sync with sync markers to prevent loops
- A single webhook endpoint that identifies the provider from request headers
- Webhook signature verification per provider
- Issue, pull request, comment, and push event handling
- Auto sync cron command with options for a single synchronisation, one company, or recent changes only
- Manual sync on demand, and enable or disable without deleting the mapping
- Synchronisation history log per mapping
- Branch creation from a work item on GitHub, GitLab, and Bitbucket
- Pull request creation on GitHub and merge request creation on GitLab
- Work item link resolution from branch names and event payloads
- Normalised pipeline and build recording from GitHub, GitLab, Bitbucket, and Jenkins
- Jenkins build status reading and job triggering
- Pull request gating on the linked work item's status, written back as a commit status
- Dry run behaviour for branch, pull request, gate, and Jenkins calls when no token is stored
- DevOps settings resolved per project with a company wide fallback
- DevOps summary panel on the work item
- Multi-tenant company-scoped data isolation
Compatibility
Requires the Orangescrum Self-Hosted edition running PHP 8.2+, CakePHP 4.6+, and PostgreSQL 16. The plugin folder is GitSync and it is registered in src/Application.php. Provider libraries for GitHub, GitLab, and Bitbucket plus an HTTP client are installed through Composer. Webhook endpoints have to be reachable from the provider; where that is not possible, use the auto sync cron command instead. Jenkins takes part in the build and CI surface only, since it has no issues, pull requests, or branches. Multi-tenant aware, so every token, mapping, task link, CI run, and history row is company-scoped.
Installation
A self-hosted install takes a few minutes. Buy the add-on, drop the plugin into your plugins/ directory, run the migrations, and you're live.
- 1
Buy the add-on
Purchase the Git Sync add-on from /self-hosted/pricing at $499/year per company, payable annually.
- 2
Drop the plugin into your install
Copy the GitSync/ folder into plugins/ on your self-hosted Orangescrum server.
- 3
Register the plugin and install its dependencies
Register `GitSync` in src/Application.php and install the provider libraries for GitHub, GitLab, and Bitbucket along with an HTTP client through Composer.
- 4
Run the database migrations
Run `bin/cake migrations migrate -p GitSync` to create the provider token, synchronisation, task mapping, entity mapping, history, work item link, CI run, pull request gate, and DevOps settings tables.
- 5
Create your OAuth applications
Register an OAuth application on each provider you want with the callback URL for that provider, then save the client id and secret in the connect screen. They are encrypted before they are stored.
- 6
Connect and map a repository
Connect a provider, then create a synchronisation: choose the repository, the Orangescrum project, the sync direction, and the field mapping.
- 7
Point the webhooks at your install
Add the webhook URL in the repository settings and select issue, pull request, comment, and push events. If your server cannot be reached from the internet, set up the auto sync cron command instead.
- 8
Turn on the DevOps surface
Configure the DevOps settings for the company, or per project, then try creating a branch from a work item and check that the build result comes back on the task.
Frequently Asked Questions
Which providers are supported?
▾
GitHub, GitLab, and Bitbucket for repositories, issues, comments, and webhooks, all over OAuth2, with GitLab able to point at a self-hosted instance. Jenkins is supported for build status and job triggering only, because it has no issues, pull requests, or branches to synchronise.
Can we open a pull request from a task on any provider?
▾
Branch creation works on GitHub, GitLab, and Bitbucket. Opening a pull request from a work item covers GitHub and merge requests on GitLab. Bitbucket pull request creation from the work item is not part of this add-on.
What if our server cannot receive webhooks?
▾
Use the polling fallback. A cron command runs the same bidirectional sync as the manual button for every synchronisation that has auto sync enabled, and it can be limited to a single mapping, one company, or only recent changes. That is the normal answer for an install on a private network or behind a VPN.
Will comments bounce back and forth?
▾
No. Comments carry sync markers, so a comment that arrived from the provider is recognised and not sent back as a new one. The markers are stripped from what people actually read.
How does a pull request get blocked on the work item?
▾
The gate evaluates the linked work item's workflow status and writes the verdict back to the provider as a commit status under its own context. The provider's required status check then allows or blocks the merge, so the enforcement happens where merges are actually controlled.
Can we set it up before granting real repository access?
▾
Yes. Branch creation, pull request creation, gating, and Jenkins calls all run as a dry run when no token is stored. They return the request that would have been sent and record a planned link, so you can wire the flow up and inspect it first.
Can different projects behave differently?
▾
Yes. DevOps settings resolve per project with a company wide fallback, so a repository heavy project can be configured its own way while everything else follows the company default.
Ready to deploy Git Sync on your own infrastructure?
Talk to our team about Orangescrum Self-Hosted Enterprise: your data, your servers, full control.