Redmine Git and source repository integration guide | DeployOpen

How Redmine Git integration connects commits to issues

Redmine's repository integration links each Redmine project to one or more source repositories, lets users browse commits and branches from inside the project, and turns issue references in commit messages into links from the changeset back to the issue. The result is that a reviewer looking at an issue can see the code changes that addressed it, and a developer reading a changeset can see the work item it belongs to. Redmine's SCM integration covers Subversion, Git, Mercurial, Bazaar and CVS, and the Git path is one of the most common choices for teams that already track work in Redmine.

Teams usually need this when issue tracking and source control live in separate tools and people reconcile them by hand. Typical triggers include audit requirements that ask for traceability from a requirement to the code that implements it, release managers who need to see which issues a build contains, and developers who want to reference an issue number in a commit and have the link appear automatically. Confirm which SCM types your teams actually use, since only the repositories you connect will appear in Redmine, and a mixed estate may need a decision on whether all of it belongs in Redmine at all.

What makes this harder than it looks is that the Redmine server keeps its own copy of repository history. Redmine does not simply display what the Git server holds at the moment a user loads a page. It fetches and stores changeset data so it can answer browsing and linking queries, which means the cost of a repository sits on the Redmine host as well as on the source control system. Fetch time grows with the size of the history, disk use grows with the copy Redmine keeps, and first synchronization of a large codebase can take far longer than routine updates. Ask the repository owners how large the history is, how many branches and tags are active, and whether large binary files are stored in the repository.

Permissions are the second area that depends on the repository rather than on Redmine alone. Redmine applies its own role-based access control to project pages, but the data it shows comes from a repository whose access rules are set elsewhere. Confirm who can read the repository directly, how the Redmine server authenticates to it (for example, a deploy key, a service account or a personal token), and whether that account can see branches or paths that the Redmine roles are meant to hide. A mismatch here can expose code to people who can see a Redmine project but should not see the repository.

Before you commit to a design, decide who will own the fetch schedule, how the Redmine host will be sized for the largest repository, and how you will test that a commit message referencing an issue produces the expected link and status change. Ask any implementation partner to state these items in the written scope, and confirm the exact Git and repository features that your Redmine version supports in its documentation and in a test project before you rely on them.

Which Redmine and repository pieces are involved

A Redmine repository link depends on several pieces working together: the project setting that points at a repository, the server account that reads it, the Git client on the application host, the repository host, and the fetch behavior of your Redmine version. Each card below names one piece and what to confirm before you build.

Per-project repository setting

Each Redmine project holds its own repository configuration, including the SCM type, the repository URL or local path, and the identifier used in commit references. Decide one repository per project or several, and record the mapping before anyone configures it. Check that the SCM type is set to Git and that each project points at the intended repository, since a wrong path shows changesets from the wrong code base.

Redmine server user access

The operating system account that runs Redmine must be able to read the repository. For a local repository, this means file system permissions on the repository directory. For a remote one, it means a deploy credential or SSH key stored for that account. Confirm read access with the exact account used by your web or application service, not with an administrator login, because a session that works interactively may fail under the service user.

Git client on the application host

Redmine calls the Git executable on the application host to read commits, branches and diffs. Install a supported Git version, confirm the binary is on the path of the service user, and test it with the same user and environment that Redmine runs under. Record the Git version in your build notes so that upgrades of the operating system do not change behavior without review.

Repository hosting service

The repository itself may live on a self-hosted Git server or a hosted forge. Each option changes how Redmine authenticates, how network paths are opened, and who manages backups and access. Confirm which protocol Redmine will use to reach the repository, whether the host allows read-only service accounts, and how repository permissions map to Redmine roles, so that private code is not exposed to users who lack access in Redmine.

Fetch and scheduling behavior

Redmine must update its view of a repository before new commits appear, and the mechanism for doing so depends on the version you run and how it is configured. Some setups rely on a scheduled task, others on a webhook or manual fetch, and the timing differs for large repositories. Confirm the fetch behavior for your exact Redmine version in the official documentation and test it on a copy of your largest repository.

Changeset storage in the database

Redmine stores imported commit metadata, such as revisions, authors, messages and the links between changesets and issues, in its database. These tables grow with history, so repository size affects backup duration, restore time and database load. Include them in your backup and restore tests, and confirm with your DBA how the chosen database engine handles the growth on large codebases.

Which repository access method and fetch approach to choose

This table compares the four main ways to connect Redmine to source code: a local clone on the Redmine host, read access to a remote repository, a mirror on the same network, and a per-project or shared monorepo layout. Read each row against your repository size, network paths and who maintains credentials, since the operational cost of each option differs more than its setup effort.

Option	When it fits	Operational cost
Local clone on the Redmine host	Small to medium repositories where Redmine must read history quickly and the host has disk to spare	Disk grows with history and is shared with Redmine itself. Fetches must be scheduled and monitored, and a failed fetch leaves changesets stale until someone notices.
Remote read over SSH or HTTPS with a service account	Repositories that already live on a central Git server and where you do not want a second copy on the Redmine host	Needs a dedicated read-only account and a managed key or token. Redmine depends on the network path and the remote server being up at every fetch or view.
Mirror on the same network as Redmine	Large or busy repositories where you want fetches to stay local while the source of truth remains elsewhere	Adds a second system to patch and back up. You must confirm how the mirror stays in sync and who owns recovery when it drifts.
Repository per project	Projects with independent release cycles, separate access rules and clear ownership boundaries	More repository entries to register and fetch. Each one needs its own access setup, but permission scoping in Redmine stays simple.
Shared monorepo with path-scoped projects	Teams that share one codebase and want one history and one fetch job, with each Redmine project tied to a subdirectory	One large fetch and clone to keep fast. Path filtering must be confirmed against your Redmine version, and project-level access still needs review because history is shared.

Build sequence for Redmine Git repository setup

This sequence connects one Git repository to a pilot Redmine project, proves that changesets and issue references work, and then extends the setup to the remaining projects. Each step ends with a check, so the team knows the link works before it reaches more projects.

Confirm Redmine and Git versions on the host
The platform engineer or Redmine administrator records the installed Redmine release from the Administration Information page and runs the Git version command on the application host. Confirm that both versions fall within the Redmine release line you plan to run, which should be the fully supported 7.0.x line for new work, and that the Ruby version matches the Redmine installation guide. Save both values in the change record. The step is done when the versions are written down, checked against the installation guide, and approved by the team that owns the application host.
Create a read-only service account on Git
The Git host administrator creates a dedicated service account that Redmine will use to read repositories. Grant read access only to the repositories you plan to link, and deny push rights. Use key-based authentication and store the private key where only the Redmine service user can read it. Record the clone address that Redmine will use. The check is run from the Redmine host as the service account: a clone of the pilot repository must succeed, and a test push to the same repository must be refused.
Provision storage for the repository copy
Redmine keeps its own local copy of each linked repository and reads history from that copy, so the Redmine host needs disk space for it. The infrastructure team allocates a directory on the Redmine host, sets ownership to the Redmine service user, and confirms free space against the size of the largest pilot repository. Ask your Git host team for the current repository size and expected growth before sizing the volume. The check is a write test by the Redmine service user in that directory, with the free space recorded in the change record.
Add the repository to a pilot project
A Redmine administrator opens one low-risk pilot project, goes to its settings, and adds a Git repository in the Repositories tab. Enter the identifier, the local storage path from the previous step, and the clone address with the service account. Keep the pilot project small and active so that its commits are easy to verify. The step is complete when the repository form saves without errors and a Repository tab appears in the pilot project menu.
Run the initial fetch and confirm changesets
The administrator starts the first changeset fetch for the pilot repository. Use the method documented for your Redmine version, such as the scheduled repository fetch task or the manual sync action, and watch the application log for errors such as authentication failures or permission problems. Large histories can take a long time on the first run, so plan the window with the team. The check is that the Repository tab lists changesets whose commit messages, authors and dates match the output of the Git log on the host.
Enable commit keywords and test one commit
In Administration Settings under Repositories, the administrator sets the referencing keywords that link commits to issues and the fixing keywords that can change an issue status. Limit fixing keywords to statuses your workflow allows. A developer then pushes a test commit to the pilot repository whose message references an issue ID in the pilot project. The check is that the commit appears in the issue history with a link to the changeset, and that any status change happens only when a fixing keyword was used and the status is permitted.
Roll out to remaining projects in stages
After the pilot passes, the team repeats the access, storage, fetch and keyword checks for each additional repository or project, in small batches. Watch fetch duration and disk growth on the largest codebases before adding more of them, and agree a fetch schedule that does not overlap heavy build or backup windows. Document the final configuration, including keyword settings and the service account owner. The sequence is finished when each linked project shows changesets in its Repository tab and an issue reference test passes in that project.

How commit messages reference and close issues in Redmine

When a commit message contains an issue number in Redmine's reference format, Redmine links that commit to the issue once the repository is scanned, and the commit appears in the issue's history with a link back to the changeset. This linking happens without any extra step by the developer, which is why the team's commit convention matters more than the settings themselves. Before rollout, confirm the reference and fixing keyword settings in the Redmine administration area and in each project's repository settings for the version you are installing. The exact keyword list, the status each keyword sets, and whether a keyword can close an issue all depend on the workflow configured in that instance, so treat any keyword list from a generic guide as a starting point to verify, not a fact about your installation. Decide early which keywords the team will use and which status transitions they should trigger. Fixing keywords change issue status only if the user who authored the commit has permission to make that change under the role and workflow rules for the project. A developer who holds a role without permission to move an issue to a closed or resolved status will see the reference recorded while the status stays unchanged. Check this with a test account in each role that developers actually hold, using a throwaway issue in a staging project. Also confirm how Redmine matches the commit author to a Redmine user, since an unmatched author affects which permissions apply. Several hazards cause surprises in practice. Branches and merge commits can carry the same issue reference several times, so an issue may show repeated changesets, and a keyword in a commit on a feature branch may change status before the work reaches the main line. Decide whether closing keywords should be used only on merges to the release branch, and document that rule. Commits that reference issues from other projects are a separate risk: Redmine can link a changeset to an issue in a project the committer does not normally work in, so agree whether cross-project references are allowed and how they are reviewed. Repository access rules also matter, because a changeset can be visible to users who can see the repository while the linked issue is private to a different group. Before rollout, agree a short commit message convention in writing and make it part of onboarding. The convention should state the reference format, which keywords are allowed, which branch or merge rule triggers a status change, and what to do when a commit touches several issues. Test it on a sample repository with the team's actual roles and workflows, and confirm the results with the people who will administer the instance. Repository hooks or CI checks that reject malformed messages can help, but they need their own review and maintenance, so include them in the scope decision rather than adding them informally. Finally, plan the ongoing upkeep. Keyword lists, workflows, roles and repository settings change over time, and each change can alter how existing commits are interpreted on the next repository scan. Record the settings and the convention with the rest of the project configuration, and re-test after any upgrade of the Redmine line or change to the workflow. Sibling guidance on implementation planning and upgrades covers the wider change control process.

What makes Redmine Git integration take longer on large codebases

This table lists the factors that most often lengthen a Redmine Git integration and shows how each one can be reduced before work starts. Use the last column to note what to ask a partner to quote, so that scope and effort can be compared on the same basis. The main takeaway is that repository scope and commit conventions usually matter more than Redmine itself.

Driver	Why it changes effort	How to keep it down	What to ask a partner to quote
Repository size and history depth	Large histories slow the initial fetch and every later sync, and they make the repository browser slower for users.	Limit the history Redmine reads, and confirm whether the repository browser needs full history at all.	How the initial fetch will be run, the expected sync interval, and how history limits are configured and tested.
Number of repositories and projects	Each linked repository needs its own mapping, permissions and sync job, so effort grows with the count.	Link only the repositories that issues actually reference, and group related repositories under one project.	A per-repository breakdown of mapping, permission and sync work, with the count stated in the written scope.
Branches and tags shown	Redmine lists and indexes every branch and tag it reads, which adds work to fetches and to the changeset view.	Restrict the visible branches and tags to the release lines people use, and remove stale refs from the sync set.	Which refs will be synced, how stale refs will be handled, and who decides the list.
Monorepo versus many repositories	A monorepo puts many teams and paths behind one repository, so access rules and changeset noise are harder to separate.	Decide whether Redmine should show the whole monorepo or only selected paths, and document that choice before setup.	Whether the design assumes path-level filtering, and how that filtering will be verified with sample users.
Network path between Redmine and the Git host	Slow or intermittent links lengthen every fetch and can cause timeouts during large syncs.	Place a local mirror close to Redmine, or schedule syncs during quieter hours where the network is shared.	Where the mirror or sync host will run, and how network failures will be logged and retried.
Authentication method for the service account	Redmine needs a service account that can read every linked repository, and the method chosen affects rotation, auditing and failure handling.	Use a dedicated read-only account with a documented rotation process, and avoid tying the sync to a personal login.	The authentication method, how credentials will be stored and rotated, and how a failed credential will be detected.
Number of users with repository visibility	Redmine's role-based access must match Git host permissions, so more users means more roles to test and more edge cases.	Map existing Git host groups to Redmine roles, and limit visibility to the projects that need it.	How role mapping will be tested, with the number of roles and sample users checked in the test plan.
Custom workflow rules tied to commit keywords	Rules that change issue status from commit messages need agreed keyword formats and tests for each rule.	Agree on a short list of commit keywords and issue reference formats before configuration begins.	How many keyword rules are in scope, and how each one will be tested against sample commits.
Number of Redmine instances or environments	Each instance needs its own repository configuration, credentials and sync jobs, and each environment must be kept in step.	Keep one production configuration and copy it to test environments with credentials replaced.	How many instances and environments are covered, and how configuration will be promoted between them.

How hosting model changes repository access and fetch behavior

On a single-node Redmine, the application server is the only place that needs repository access. Redmine stores repository metadata in its database and reads repository content from a local working copy or from the Git host directly, depending on how the repository is configured. Because one server handles every request, fetch scheduling, credentials and changesets all live in one place, which keeps troubleshooting simple.

What to plan for:

Repository copy: Redmine keeps its view of the repository on the same disk as the application. Size that disk for the repository history, not just the current checkout.
Git host access: The server needs outbound network access to the Git host over the protocol you choose, usually SSH or HTTPS.
Credentials: Store a single deploy key or service account for the Redmine process, with read-only scope where the host supports it.
Firewall rules: One egress rule set covers the whole installation. Document it so auditors can match it to the approved repository list.
Fetch behavior: Fetches run from one host, so a slow fetch affects only that server's schedule.

Before you go live, confirm with your Git host and your Redmine version how repository fetches are scheduled and which credential types are supported for your chosen protocol.

How to test that Redmine Git integration works and fails safely

The first test to run is the simplest one: push a new commit to a repository linked to a Redmine project, trigger a repository fetch, and confirm that the commit appears in the project's changesets. Record the repository identifier, the commit hash, the branch and the time of the push, so the same check can be repeated after every configuration change. Then repeat it with a commit that references an issue ID in its message, for example a message that names an existing issue in the form Redmine's documentation describes for referencing issues. The commit should appear both in the changesets and on the referenced issue's history. If the changeset appears but the issue does not, the reference pattern or the project's repository association is wrong, and that is the first thing to fix before rollout. Confirm the exact keywords that close issues on the Redmine version you run, because the list of supported keywords is configurable and should be checked against your own settings rather than assumed. The permission test needs a dedicated user with an account that has no role in the project that owns the repository. That user should not see the Repository tab, should not see the changesets through the project page, and should receive an access denial when opening a changeset URL directly. Repeat the check with a user who has read access to the project but not to the repository module, because a project can be visible while its repository is hidden. Also check that a private project does not leak its changesets through search or the activity feed. Run the same test once with each authentication path your organization uses, such as local accounts and LDAP, since group membership may be mapped differently. Record the role matrix used for the test so the result can be reproduced. The failure tests matter as much as the success tests. Simulate a Git host outage by blocking network access from the Redmine server to the repository host, then trigger a fetch and confirm that Redmine shows a visible error in the repository view or the administration log rather than silently showing stale data. Next, revoke or rotate the credential Redmine uses to read the repository, trigger a fetch again, and confirm the same visible error. After each failure, compare the existing changesets, their count and their referenced issues with the values recorded before the test. History that was present before the outage should still be present and unchanged after recovery, and a fetch after access is restored should add only the commits that were missed. Do not run these tests against the only copy of production data. Use a staging copy of the repository and database. Finally, test with a large history. Choose a repository with the largest commit count your teams actually use, and measure how long an initial fetch and an incremental fetch take on the production-sized hardware. Record the baseline values, the Redmine version, the database engine, the Git version and the server specifications, because fetch time depends on all of them. Ask your implementation partner or your platform team to confirm which fetch scheduling and caching options apply to your Redmine version before setting any target. After the rollout, rerun the same large-history fetch under the same conditions and compare the results with the baseline. A slower result is a signal to review repository size, scheduling and background job capacity before users notice delays.

Securing the repository credentials and visibility Redmine exposes

Redmine adds its own exposure on top of the Git host's controls. Each card covers one place where a service account, a stored credential or a Redmine role can reveal more repository content than intended, so review them together before the integration reaches production projects.

Dedicated read-only service account

Create a separate account on the Git host for Redmine to fetch and browse repositories, and do not reuse a developer's login. Redmine only needs to read, so the account should hold no push rights, no branch protection bypass and no administrative role. Name it clearly so host audit logs show which system performed each fetch. Confirm whether your host allows interactive logins for service accounts and disable them if it does.

Least-privilege repository permissions

Grant the service account read access only to the repositories that Redmine projects link to. Repositories with no Redmine project should stay outside its scope. Review group memberships on the host, because access inherited from broad organization groups often exceeds what the integration needs. Confirm the exact permission names in your Git host's documentation, since they differ between hosting platforms.

Keeping the credential out of view

Redmine needs the service account's secret to fetch repositories, so enter it only in the repository settings for each project and limit who can open those settings. Check whether the settings form shows the stored value after saving. After a test fetch, search the Redmine log, web server logs and any job logs for the secret. Treat database backups and exports as sensitive, because the stored value may be included.

Restricting repository browsing and changesets

Redmine role permissions decide which roles can browse the repository tree, view file contents, and see changesets and diffs. Review these settings per project for every role, including the role given to anonymous visitors and roles given to people outside your organization. A public project with a repository tab can expose source code to unauthenticated visitors if anonymous roles are set too broadly.

Reviewing private code in search and wiki links

Commit messages, changesets, file names and paths become searchable in Redmine, and wiki pages and issues can link to commits and files. Run global and project search as each role to see what a member can find. Check that wiki and issue text does not paste code, tokens or internal hostnames, and that links to private repositories are visible only to the intended audience.

Controls covered in sibling topics

General Redmine hardening, per-user API key handling and HTTPS configuration are covered in the Redmine security hardening and REST API integration topics. Use those for server, session, transport and API controls. Use this topic for the repository-specific items above, and confirm that both sets of controls are in place before the integration goes live.

What to monitor, back up and document after go-live

After go-live, the signals that show the integration is failing are usually quiet. Watch the changeset fetch job for errors, and compare the most recent changeset shown in each Redmine repository with the latest commit on the Git host. A gap that keeps growing means fetches are failing or stalled, often because the server can no longer reach the remote, the local copy is in an unexpected state, or a branch was force-pushed. Stale changesets also mean that commit references and automatic issue closing are not happening, so developers may assume work is linked when it is not. Set an alert on fetch errors and on the age of the newest changeset per repository, and review both during the first few release cycles. Confirm with your installation guide how the fetch job is scheduled and where its logs are written.

Three other items need an owner. First, the disk footprint of the local repository copy grows with every push, and large histories or large binary files can make it grow faster than teams expect. Track disk usage on the volume that holds it and agree in advance how repository maintenance will be handled. Second, the service account that Redmine uses to read from the Git host has a credential that expires or is rotated on a schedule. When it changes, fetches fail silently until someone notices, so record the expiry date and test fetches after each rotation. Third, permission changes on the Git host, such as removing a team from a repository or making it private, can break the mapping between Redmine projects and repositories. Review these changes on the host periodically, and cover Redmine upgrades in the sibling upgrades topic, since a new Redmine release can change how the SCM integration behaves.

Back up the Redmine database first. It holds the changeset records, the repository and project links, and the issue references that the integration depends on, so losing it means losing the history of how commits were linked to issues. Back up the configuration files, including the repository settings and any environment-specific configuration, and keep them with the database backup so that both can be restored to the same point in time. The Redmine upgrade guide calls for the same database and file backups before any upgrade, so use one backup routine for both purposes. The local repository copy does not need to be backed up as a primary record, because it can be rebuilt by cloning from the Git host. Confirm that a restore test rebuilds the copy and that the fetch job then fills in the changeset history from the restored database.

Documentation is what allows someone other than the original builder to run this integration. Record the mapping between each Redmine project and its repository, including the repository path, the default branch and any branches that are intentionally excluded. Record the commit convention that teams must follow to reference and close issues, with examples taken from your own workflow, and state which keywords are recognized. Name the owner of the service account, the team that approves changes to it, and the step-by-step rotation procedure, including where the new credential is stored and how fetches are tested afterward. Keep this record in a location the platform team controls, and review it at each Redmine upgrade and at each change to the Git host's permissions.

Questions teams ask before hiring help with Redmine Git integration

What drives the cost of a Redmine Git integration project?

The cost comes from people and server work, not a license. Redmine is free under GPL v2, so you will not see a software fee. The main cost drivers are the number of repositories and Redmine projects to link, whether repositories sit on a Git host you control or a third-party service, how many commit conventions must be agreed, and whether the Redmine server needs upgrading first.

One-time costs include scoping, configuration, the first repository fetch, testing and handover. Recurring costs include server resources, scheduled fetches, and administrator time when repositories move, credentials rotate or Redmine is upgraded. Ask any quote to separate these lines and state the assumptions behind each one.

How long does Redmine Git integration take, and does repository size matter?

Duration depends mainly on repository size and the number of projects linked. No duration figure applies to every installation, so confirm the estimate in writing and ask what it assumes.

Larger repositories, meaning long history, many branches and tags, take longer for the first fetch and can slow repeated fetches on a busy Redmine server. Each additional project adds mapping, permission checks and test cases. A sound plan tests fetch intervals against a copy of the largest repository before production. Ask the provider to state the repository count, the size of the largest repository, the fetch schedule used in the estimate and how they tested it.

Can an internal Redmine administrator set up Git integration alone?

Often yes for one small repository, but rarely for a large estate alone. An administrator with Redmine admin rights and server access can usually link a single repository that they can already read.

The work also reaches areas a Redmine administrator may not normally own: credentials or deploy keys for the Git host, network paths from the server to the host, scheduled fetch jobs, file system permissions and the commit message rules that update issues. Teams with many projects, a large history or strict access rules usually need a second person who owns the Git host. Before touching production, confirm the administrator's skills in Linux services, Redmine deployment and Git, and plan a test project first.

What does the client need to provide for a Redmine repository integration?

The client provides access, owners and decisions. Before work starts, a typical engagement needs:

Repository access: read access for the server, with credentials or keys the client can rotate.
A Git host owner: a named person who can approve service accounts, webhooks and access changes.
A commit convention: the agreed format for issue references and the keywords that change issue status.
A test project: a non-production Redmine project and a sample repository for acceptance testing.
A Redmine owner: someone who can approve changes to the server and its upgrade state.

Missing any of these usually delays the schedule more than the technical work does.

Do Subversion or Mercurial repositories change the Redmine integration work?

Yes, the connector setup, test plan and operations differ, although the goal is the same. Redmine's feature set includes SCM integration with Subversion, Git, Mercurial, Bazaar and CVS, so the basic linking of projects to repositories is similar across them.

Effort changes with the SCM type, the repository client tools on the server, how each history and branching model appears in Redmine, and how commit references work in that system. Confirm the installed Redmine version and the repository client versions before estimating. If your estate mixes SCMs, ask for each one to be listed separately with its own test cases and fetch behavior.

How does Redmine link commit messages to issues, and what usually breaks?

Redmine reads issue numbers in commit messages and can apply configured changes to those issues. The exact keywords and options depend on the Redmine version and configuration, so confirm them against the installed release before the commit convention is written.

Common failures include commits without issue identifiers, identifiers that point to the wrong project, fetches that fail after a credential expires, repositories that are not reachable from the Redmine server and branches that never get fetched. Good test cases include a commit that references an issue, one that closes it, one from an unauthorized user and one that uses an unknown identifier.

What should a fixed-scope quote for Redmine Git integration list?

A fixed-scope quote should list what is in, what is out and what the client must supply. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and a quote follows from that written scope.

Ask for these items: the Redmine version and hosting environment; each repository and SCM type in scope; the commit convention and issue keywords; credential and access handling; the fetch schedule and the performance test method; the test project and acceptance criteria; documentation and handover; exclusions; client responsibilities; and the timeline. Ongoing support after go-live is available as a retainer, so ask for it as a separate line.

How DeployOpen scopes, builds and hands over Redmine repository integration

DeployOpen plans and implements Redmine Git and source repository integration inside your own infrastructure, starting from a written scope that names the repositories, projects and commit conventions involved. The work is delivered as documented configuration you can run, verify and maintain without depending on us for routine operation.

How we scope

Inventory which Git, Subversion or Mercurial repositories must link to which Redmine projects, and who needs read or write access.
Agree the commit message reference and closing keywords your teams will use, and how they map to issue status changes.
Record the repository sizes, branch counts and fetch frequency that will shape the cache and fetch settings.

How we build

Configure repository entries per project in a staging instance, then test referencing and closing from sample commits before production use.
Tune repository fetch and caching on the largest codebases, using measurements from your own repositories rather than assumed values.
Confirm SCM access credentials are stored and rotated under your existing secrets practice, not hardcoded in project settings.

How we hand over

Deliver a runbook covering each linked repository, its permissions, the commit keyword conventions and the fetch configuration.
Provide a test checklist your team can rerun after upgrades, covering commit referencing, closing and repository browsing.
Walk your administrators through troubleshooting failed fetches and reviewing role access for repository views.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the fixed-scope integration.
Retainer work can cover re-validating repository links when Redmine moves between supported 7.0.x releases and plugin updates.
Ask any support proposal to state which repository types, Redmine versions and plugins it covers, and how changes are logged.

Redmine Git and source repository integration