The docs have been restructured for better navigation. Found a broken link or have feedback to share? Let us know
here.
Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Git

Starting with IDA 9.4, Git is the default version control backend for all new repositories.

Teams Git integration follows the standard software development workflow, using familiar version control concepts, adapted for working with IDB files.

The Git backend eliminates the need for a dedicated Teams server. If your team already has a GitHub, GitLab, or self-hosted Git account, that's all you need.

Migration from Vault

If you have existing Vault repositories, a dedicated migration tool makes moving to Git straightforward.

See the Vault to Git Migration tutorial to get started.

To keep using Vault, go to Options → General → Teams and select Vault under the Teams backend dropdown. The Teams menu updates to reflect the familiar Vault actions.

Key Concepts

  • All operations apply to the currently open database.

  • The Git backend is accessible directly from the Teams menu, with available Git-native actions, like Commit, Push, Pull, and more.

  • A small helper, git-ida, lets Git store and reconstruct IDA databases efficiently. It runs transparently during commits and checkouts. You only interact with it directly from a terminal or a script. See Using git-ida from the command line.

Branching

IDA works with whichever branch is currently checked out in the repository. The status bar shows the active branch name at all times.

Switching branches is not yet supported from within the IDA GUI. Use the command line with standard Git commands:

See Switching branches in the Using git-ida from the command-line guide.

Automerging and Merging

When you pull and the remote has changed since your last sync, IDA needs to reconcile two diverged versions of the same IDB. It does this with a three-way merge: it takes your local copy, the remote copy, and the last common ancestor (base), and computes a result that incorporates both sets of changes.

IDA always attempts an automatic merge first. A background IDA instance runs the merge without any user interaction. Most everyday divergences (renames at different addresses, comments on separate locations, non-overlapping type changes) are resolved at this stage automatically, and the result is saved as a merge commit.

If the automatic merge cannot resolve everything, IDA falls back to the interactive merge view, presenting the three versions side by side so you can decide each conflict manually. Once you finish and save, IDA records a merge commit and reloads the database in your main session.

The merge result is always recorded as a commit in the repository history.

For the step-by-step procedure, see Resolving Conflicts.

Last updated

Was this helpful?