TortoiseGit: a Windows shell extension for Git

What TortoiseGit is, and where it came from

TortoiseGit is a Windows Shell Interface to Git based on TortoiseSVN, and the README describes it as open source and buildable entirely with freely available software. The subject is the regular tasks of version control, with committing, showing logs, diffing two versions, creating branches and tags, creating patches and so on, all reachable from the file manager. That is the whole proposition. A shell extension puts the version control operations in the right-click menu of a file or a folder, so the workflow stays in Explorer rather than splitting between a file browser and a terminal. The primary language is C++, the default branch is `master`, the last push was on 2026-09-27, and the repository has no GitHub releases, since the project publishes its binaries on its own site. The licence is GPLv2, with the text at `src/gpl.txt`.

The repository is a mirror, and the real home is tortoisegit.org

The project description says plainly that this is a mirror of the official repository at tortoisegit.org/sourcecode, and that matters for how you read the tree. The top level is the whole project, with `src/` for the C++ sources, `Languages/` for the translation files, `doc/` for the documentation, `ext/` for external dependencies, `contrib/` for contributed material, `test/` for the tests. There are also a `build.txt` file with all the requirements and steps for building, an `architecture.txt` with a short description of how the code is arranged, a `release.txt`, and a `.gitlab-ci.yml` with a `.gitlab-ci/` directory, which is where the build automation lives. The `doc/readme.txt` file is the entry point for documentation contributions, and `Languages/README.txt` covers translations, so the documentation and the localisation are both first-class contributions in the tree rather than in a separate site.

How to contribute, and the five ways in

The contribution section lists five kinds of help, and the list is a good description of what a project of this age and type actually needs. You can improve the documentation, following the `doc/readme.txt` file and the `doc` folder. You can work on translations, with the `Languages/README.txt` guide. You can test the preview releases, which are published on an irregular basis and are built from the latest code, representing the most recent development. You can help other users on the mailing lists. And you can improve the user interfaces, or code, fixing open issues and implementing features. Issues and merge requests are both welcome, and the contribution guidelines in `CONTRIBUTING.md` describe the workflow.

Preview releases, and how the download works

The latest release and the language packs are on the download page, and that page also carries the system requirements and the latest release notes. The preview releases are a separate stream, published on an irregular basis and used by the developers themselves, built from the latest code rather than from a tagged release. That distinction is worth understanding before you report a bug, because the README's first instruction for anyone with a problem is to search whether a similar issue already exists and to check whether the problem is not already fixed in the latest preview release. The download page is also where the system requirements live, which is the first thing to check before installing a shell extension, since a shell extension is loaded into Explorer.

Reporting a crash, and the crash reporter

There is a dedicated section on what to do if things go wrong, and it sets out the expectations for a report. An important aspect of reporting issues is to have a reproducible example, and it is also important to mention the exact version of your operating system, the version of Git and the version of TortoiseGit, the last of which is on the about dialog. The mechanism for reporting is the crash reporter, which is included unless it was disabled at installation and automatically uploads crash dumps to drdump.com, where the team can review them, and the README asks you to file an issue as well and link the crash report. There is also a special page describing the steps for debugging, at `src/Debug-Hints.txt`, and the point of it is that the majority of those steps do not require you to build TortoiseGit yourself.

Where to get help, and the mailing lists

The README lists the channels in one block, and it covers both users and developers separately. The website is tortoisegit.org, with a download page, documentation, a support page and an issue tracker, plus a contribute page. There are three mailing lists, and the naming is the point, since tortoisegit-announce is for releases, tortoisegit-users is for people using the software, and tortoisegit-dev is for people working on it. There is also a StackOverflow tag. The `SECURITY.md` file in the repository root is where a security report should go, and the `CONTRIBUTING.md` file holds the workflow. The `appveyor.yml` at the root is the Windows continuous integration configuration, which for a C++ Windows application is the natural place for the build to be exercised.

Editorial conclusion

Adopt TortoiseGit if you work on Windows and want Git operations without a terminal, particularly for diffing, reviewing history and making patches. Skip it if you are comfortable on the command line, since the shell extension is the point rather than a performance choice. Before you install, check the system requirements on the download page, since it is a Windows-only application, and note that the licence is GPLv2 and that the repository carries no GitHub releases, so the release history is on the project's own download page rather than in tags.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. TortoiseGit/TortoiseGit on GitHub