# GitQlient: a Qt desktop Git client that grew past its QGit fork > GitQlient is a multi-platform Git client written in C++ with Qt, forked from QGit and extended with submodule management, stashes, multi-repository windows, GitHub and GitLab integration and an embedded editor. It is packaged as an AppImage, an RPM, a deb, a Windows installer and a MacPorts port, and its desktop release history has a gap that the continuous build papers over. **francescmaestre/GitQlient** — GitQlient: Multi-platform Git client written with Qt. - Repository: https://github.com/francescmaestre/GitQlient - Website: https://www.francescmm.com - Stars: 891 · Forks: 86 - Language: C++ - License: LGPL-2.1 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/francescmaestre-gitqlient ## The problem: a Git client that is not a browser window Most people who want a graphical Git client are choosing between a web interface, an IDE plugin, and a native desktop application. The first two are not really choices for someone who wants to manage several local repositories, read a diff comfortably, and keep the Git operations on their own machine. GitQlient is a multi-platform Git client written with Qt, and it started life as a fork of QGit. The documentation is candid about that: it goes beyond of just a fork and adds a lot of new functionality. The name is a pronunciation guide as well, git+client, which tells you what the author thought the app was. The audience is desktop users who want a proper GUI over a local working copy, with the operations that a Git power user needs grouped into panels rather than scattered across menus. The feature list in the project description covers remote actions such as push, pull, submodule management and branches, branch management, tags and stashes, submodule handling, opening several repositories in the same window, better visualisation of commits and of work in progress, better visualisation of the repository view, GitHub and GitLab integration, and an embedded text editor with syntax highlighting for C++. The last two are the ones that tell you what kind of user this is for. A GitHub integration and an embedded editor with C++ highlighting are not features for a general consumer. They are for a developer who wants to look at code inside the same window as the history of it, without leaving the client to open an editor and a browser tab. The licence is LGPL-2.1, the default branch is master, and the last push was on 2026-05-10. ## What the client does, and what the fork gave it The QGit inheritance is visible in the shape of the application, and the additions are visible in the feature list, so it is worth separating them. From the fork came the core client structure: a Qt desktop application that presents the repository, its history and the working tree, with a layout that was designed for a graphical interface rather than adapted from a terminal. The repository top-level entries confirm the tooling: a CMakeLists.txt alongside the older GitQlient.pro and GitQlientApp.pro qmake project files, a .clang-format configuration for the C++ sources, a .gitmodules file, and a src/ directory with the icons under src/resources/icons. What the project added is the parts a modern Git user expects and QGit never had. Stashes, which QGit predates as a concept in most distributions. Submodules, which are fiddly enough that having them in the client is a real convenience. Multiple repositories in one window, which is what a developer with a work project, a dotfiles repository and a fork of something else actually needs. And the integrations: GitHub and GitLab, so pull requests and issues sit next to the commit graph rather than in a separate tab. The embedded editor is the most unusual inclusion. Syntax highlighting for C++ is a narrow choice, which suggests the editor is there for the specific case of looking at or tweaking a source file while working with the history of it, rather than as a general purpose IDE panel. For the full picture, the project points at the release notes in its wiki, since the description explicitly says to take a look there for all of the features. ## Installing on Linux: an AppImage or an official Fedora package Linux is the platform the project develops on, and it is also the first one to be released. The documentation says so explicitly: the development environment is based on Linux and it will be the first platform released, even though releases are planned for Linux, MacOS and Windows. There are two routes. The first is the AppImage, which the documentation describes as a big binary that includes all the libraries needed to run, and a portable multi-OS version, so you download the version you want from the releases page and execute it, making sure it has execution rights. That is the zero-friction route and the one to try first if you are evaluating the client. The second is a native package. GitQlient is packaged in the official Fedora repositories, and the install is: ```bash sudo dnf install gitqlient ``` For Debian and Ubuntu there is no package in the official repositories, and the documentation links the Ubuntu bug that tracks it. In the meantime you download a .deb from the releases page and install it with apt-get as root. The packaging status across the ecosystem is tracked through a repology badge, which is the fastest way to see which distributions carry it and at what version. That matters for a project with a long gap between tagged releases, because a distribution package will be pinned to whatever version the distribution froze. The user manual is linked from the project description and has an appendix dedicated to building GitQlient and the dependencies it needs, which is the reference to check before compiling it yourself. ## Windows, macOS and the quarantine flag problem Windows is the straightforward case. For Windows 10 there is a package provided on every release, and the documentation says it installs all the dependencies and creates a shortcut on the desktop. You download the GitQlientInstaller-.exe binary from the releases page for the version you want. macOS is the one with a caveat, and the documentation does not hide it. There is a DMG package you can install as usual, but you have to take into account that because of lack of resources this version is not tested. That is an unusual thing for a project to write about its own macOS build, and a reader should treat it as a statement about the level of assurance rather than about the package quality. The DMG also produces a familiar problem: macOS Gatekeeper quarantines applications downloaded outside the App Store, and the symptom is that the app appears damaged and cannot be opened. The documentation gives the fix, pointing at issue 234: ```bash sudo xattr -rd com.apple.quarantine /Applications/gitqlient.app ``` That command removes the quarantine attribute recursively from the application bundle, which is the standard workaround for a locally built or downloaded macOS binary. There is a third option for macOS through MacPorts: ```bash sudo port install gitqlient ``` So a macOS user has three routes, an untested DMG, a MacPorts port, and the quarantine workaround if the first one misbehaves. That is a rougher path than the Fedora package or the AppImage, and it is the platform where the project's own documentation shows the least confidence. ## The interactive UI guide, and the manual that carries the build steps Two pieces of documentation stand out, and both are unusual for a project of this size. The first is the interactive UI guide, a small and, in the author's words, ugly webpage for developers who want help understanding the different parts of the UI of GitQlient and how they are connected with the C++ code. It shows the current UI design with links to the code of the widgets when you click on areas of the image, and the code is displayed in a frame next to the image, so a 1920 pixel screen might be needed. That is a genuinely useful artefact for a Qt application, because a Qt UI is defined in code and the mapping from a pixel to a widget class and a slot is not obvious to someone reading the repository. The author is also honest about the limits: the guide is only updated with major releases, and he says he is not a web developer and does not intend to dedicate much time to it. The second is the user manual, hosted as its own site, which the documentation recommends both for learning the client and for its appendix on building GitQlient and the dependencies required. For a project whose binaries lag behind its source, the manual is also the place where a reader can see the current shape of the interface. Translations are handled through the translation system of Qt, which means every new language needs two files, a .ts file with the text translation and a .qm file, the compiled file the client will load, and both have to be added to the resources.qrc. Using the platform's own translation tooling rather than a custom one means existing Qt Linguist workflows and existing translators apply. ## The release gap, and the continuous build that covers it The release history is short and irregular, and it is the thing a prospective user most needs to understand. The tagged versions are v1.6.3 from 2024-10-06 and v1.6.2 from 2023-09-09, with a continuous build tagged dev-latest on 2026-04-21. So the last stable release is roughly two years old, while the development branch has been producing a fresh build. That shape has a sensible rationale for a desktop application whose binary is distributed through package managers and through download pages. A rolling dev-latest build lets people who want the newest code get it, while the tagged releases stay as the conservative option. For a distribution such as Fedora, the package will follow the tagged line, which means a user of an official RPM is likely running code that predates the current UI. The documentation supports the choice by pointing at the release notes in the wiki for the full feature picture, and the project carries a CI badge for the master branch, so there is a signal about whether the tip of the branch builds. For an adopter, the practical questions are narrow. Which version do you want, the tagged release or the rolling build. And does the version you pick support the Git operations your team relies on, because the feature list in the description is a summary of the major ones and the wiki release notes are where the detail lives. The icons and fonts are worth a short note for anyone redistributing the application. Most of the icons come from Font Awesome, whose licence is described as GPL friendly, and the rest are custom. The fonts are DejaVu Sans and DejaVu Sans Mono, a free font used by most Linux distributions. Both are compatible with the project's own LGPL-2.1 terms, which is the sort of housekeeping that a project that forked an existing client tends to have already done. ## Who should use it, and what to check first The honest case for GitQlient is a developer on Linux or Windows who wants a native desktop Git client with submodule and stash handling, several repositories in one window, and hosting integration for GitHub or GitLab in the same window as the history. If your work involves submodules regularly, or you juggle several checkouts, the feature set is aimed squarely at that. The case against is a project that needs a reliable release cadence, a documented upgrade path and a build you can reproduce. The last tag is from October 2024, the macOS build is described as untested, and the source of truth for what changed is a wiki rather than a changelog in the repository. It is also not the right tool if you want Git in an editor. A Git client with its own embedded C++ editor is a different thing from an IDE plugin, and if your workflow already lives inside an IDE you have probably already made this choice. Three checks before you install. First, the feature coverage for the version you are about to take, through the wiki release notes, because the description lists only the major features. Second, if you compile rather than install a package, the build appendix in the user manual, which is where the dependencies are listed, since the repository also carries both a CMakeLists.txt and the older qmake project files. Third, on macOS, whether you are prepared to run the xattr command to clear the quarantine attribute. The licence is LGPL-2.1, which lets you use and modify the client and requires that modifications to the library itself be shared, and the project is distributed as free software. For a desktop tool, the practical question is not the licence but the maintenance signal, and that signal comes from the last push on 2026-05-10 and the continuous build that goes with it. ## Conclusion Adopt GitQlient if you want a native desktop Git client with submodule and stash handling, several repositories in one window, and packaging that includes Linux, Windows and macOS. Do not adopt it if you need a maintained release cadence you can pin, because the last tagged version is v1.6.3 from 2024-10-06 and only a continuous development build is newer. Before you install, check whether the version you take supports the Git features your team relies on, since the feature list is a summary and the wiki release notes carry the detail, and read the build appendix in the user manual if you intend to compile it. ## FAQ ### How do I install GitQlient on Linux? GitQlient is offered as an AppImage that bundles its libraries, which you download from the releases page and execute, and it is also packaged in the official Fedora repositories, where the install is sudo dnf install gitqlient. There is no package in the official Debian or Ubuntu repositories, so on those you download a .deb from the releases page and install it with apt-get as root. ### Why does GitQlient fail to open on macOS? The application may be blocked by the macOS quarantine attribute, which produces the appearance that the app is damaged. The documented fix is to run sudo xattr -rd com.apple.quarantine /Applications/gitqlient.app, and the project also notes that the macOS version is not tested because of a lack of resources. ### What does GitQlient add to the QGit code it was forked from? The project states that it goes beyond being just a fork and adds a lot of new functionality: easy access to remote actions such as push, pull, submodule management and branches, branches management, tags and stashes management, submodule handling, several repositories in the same window, better visualisation of commits and of the repository view, GitHub and GitLab integration, and an embedded text editor with C++ syntax highlighting. ### How do I add a translation to GitQlient? GitQlient uses the translation system of Qt, so a new language needs two files, a .ts file with the text translation and a .qm file which is the compiled file the client loads. Both have to be added to the resources.qrc, and the Qt Linguist documentation is linked for the detail. ### What licence is GitQlient released under? LGPL-2.1. The icons are mostly from Font Awesome, whose licence is described as GPL friendly, with the rest custom made, and the fonts are DejaVu Sans and DejaVu Sans Mono, which are free and used by most Linux distributions. ## Sources - [francescmaestre/GitQlient on GitHub](https://github.com/francescmaestre/GitQlient) - [License: LGPL-2.1](https://github.com/francescmaestre/GitQlient/blob/master/LICENSE) - [Project website](https://www.francescmm.com) - [README](https://github.com/francescmaestre/GitQlient/blob/master/README.md) - [Releases](https://github.com/francescmaestre/GitQlient/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/francescmaestre-gitqlient