# Working with Git
This tutorial covers the most common, day-to-day tasks you will want to perform on your IDBs with the Git backend.
{% hint style="success" %}
Using Vault already? See the [Vault to Git Migration](/9.4/add-ons/teams/how-tos/migrating-from-vault-to-git.md) tutorial to get started.
{% endhint %}
All the commands described here live under the **Teams** menu. When a Git repository is open, the IDA status bar also shows the current workspace, remote, branch, user, and the version of the `git-ida` driver in use, so you always know what context you are working in.
***
## Before you begin
Not set up yet? Start with the [Git backend setup](/9.4/add-ons/teams/getting-started/getting-started-git.md#setup) first.
***
## Committing
A commit captures the current state of your IDB in the repository history.
1. From the **Teams** menu, choose **Commit**.
2. Enter a short message describing what changed (e.g. *"Renamed crypto helpers and annotated the dispatcher"*). The commit message field keeps a history, so previously used messages are available from a drop-down.
3. Click **Commit**, or — if the repository has a remote — **Commit and Push** to also publish the commit to the server in one step.
Behind the scenes IDA:
* Saves the database to disk.
* Stages the IDB file.
* Records a commit authored by your configured Git identity.
* Optionally pushes the new commit to the remote.
If you ever just want to publish commits you already made (for example, because you chose **Commit** without pushing), use **Teams → Push**. If the remote has moved forward in the meantime, the push will fail and IDA will suggest that you pull first — see the next section.
{% hint style="info" %}
There is no separate "stage files" step. IDA always commits the current IDB. Auxiliary files such as `.gitignore` and `.gitattributes` are managed automatically when the repository is created or cloned.
{% endhint %}
***
## Synchronizing files
Synchronizing means making sure your local copy and the remote both have each other's latest commits. IDA exposes two complementary operations:
| Action | Direction | What it covers |
| ---------------- | ------------ | ---------------------------------------- |
| **Teams → Pull** | server → you | The current IDB only. |
| **Teams → Push** | you → server | All local commits on the current branch. |
### Pulling
When you choose **Teams → Pull**:
1. IDA saves your current database so nothing in memory is lost.
2. IDA fetches from the remote. If you are already up to date, the operation finishes immediately.
3. If the remote has new commits for this IDB, IDA extracts three versions side by side:
* **local** — your current working copy,
* **remote** — the latest version on the server,
* **base** — the last common ancestor of the two.
4. A second IDA instance is launched in the background to attempt an **automatic three-way merge**. If it succeeds, the merged result is saved back as a new merge commit on top of your branch, and your IDB is reloaded with the merged content.
5. If automatic merging fails because of conflicts, IDA offers to open the interactive merge view — see [Resolving conflicts](#resolving-conflicts) below.
### Pushing
**Teams → Push** publishes your local commits to the remote branch. If this is the first time you push from a freshly created repository, IDA also configures the upstream tracking branch for you.
If the push is rejected because the remote has diverged from your local copy, pull first to integrate the remote changes, then push again.
### Managing several repositories at once
If you work on multiple repositories, **Teams → Manage Repositories** opens a chooser listing every repository IDA knows about (path, branch, and remote).
Right-clicking a row lets you **Pull** or **Push** that repository without having to open one of its databases first. The **Delete** entry removes the repository from disk and from IDA's list (it is disabled if a database from that repository is currently open).
***
## Viewing the history of an IDB
To browse past versions of the currently open IDB, use **Teams → History**.
The dialog lists up to 100 most recent commits that touched this IDB, with columns for:
* **Commit** — short hash,
* **Date** — commit date,
* **Author** and **Email**,
* **Message** — your commit summary.
From this view you can:
* **Compare two revisions.** Select two commits (Ctrl + click in the chooser) and press Enter, or right-click and pick **Compare revisions**. IDA extracts the two versions of the IDB and launches a side-by-side comparison in a new IDA window, using the same diff view used for decompiler comparisons.
* **Compare a revision with your current work.** Select a single commit, right-click and pick **Compare with working copy**. IDA saves your current database, extracts the chosen revision, and opens a diff window between them.
The comparison runs in a separate IDA instance, so your current session is never disturbed.
{% hint style="info" %}
For a quick check of what you have changed since your last commit, you don't need to go through the **History** dialog — see [**Local Changes**](#local-changes-at-a-glance) below.
{% endhint %}
### Local changes at a glance
**Teams → Local Changes** is a shortcut for comparing your current unsaved/uncommitted IDB against the last committed version (`HEAD`). IDA saves the database, extracts the HEAD version, and opens the diff view between them. This is the fastest way to review what is about to go into your next commit.
***
## Reverting changes
If you want to discard everything you have done since the last commit and start again from a clean slate, use **Teams → Revert Local Changes**.
1. IDA asks you to confirm. The current uncommitted state of the IDB is about to be thrown away, and **the operation cannot be undone**.
2. On confirmation, IDA restores the IDB file from the last commit (`HEAD`) and automatically reopens the database so you immediately see the reverted version.
Reverting only affects the *current* IDB; other files in the repository are not touched. If you need a more selective rollback (for example, going back to a much older revision), use **History** to extract the revision you want and overwrite the current IDB by hand, then commit the result.
***
## Resolving conflicts
A conflict happens when the same IDB has been changed both locally and on the remote since you last synchronized. IDA tries hard to resolve conflicts for you, and only asks for help when it really cannot decide.
The conflict flow is triggered automatically when you **Pull**:
1. **Automatic merge.** IDA launches a background IDA instance that attempts a fully automatic three-way merge between your local copy, the remote copy, and their common ancestor. Most everyday conflicts — distinct renames, comments on different addresses, non-overlapping type changes, etc. — are resolved at this stage without any user interaction.
2. **Interactive merge.** If the automatic merge cannot decide, IDA shows a message saying *"Automatic merge failed due to conflicts. Do you want to resolve conflicts manually?"*. Choosing **Yes** opens the standard IDA merge view in a new window, showing the three versions side by side:
* **(local)** — your current database,
* **(remote)** — the version from the server,
* **(base)** — the common ancestor.
3. **Resolve each conflict.** Work through the conflicting items in the merge view, selecting the version you want to keep (or editing the result) for each one. Use the same merge tooling you would use for any other IDA database merge.
4. **Finish the merge.** Save and close the merge window when you are done. IDA picks up the merged database, records a merge commit on top of your branch (`Merge origin/ into `), and reopens the merged IDB in your main session.
If you decide *not* to merge after all — for example, you would rather review the remote changes more carefully first — answer **No** at the prompt. Nothing is committed, and your local IDB is left untouched.
### Avoiding conflicts in the first place
* **Commit often.** Small, focused commits give Git (and IDA) the best chance of merging automatically.
* **Pull before you start a longer session.** Bringing the remote changes in early keeps the divergence window short.
* **Coordinate on large refactors.** If you are about to restructure a big portion of a binary (mass renames, big struct rewrites, etc.), let your team know so others can pull first.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.hex-rays.com/9.4/add-ons/teams/how-tos/working-with-git.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.