Alternatives à GitKraken : choisir un client Git adapté à votre workflow

Les critères qui comptent : graphe, staging, rebase et plateformes

Pour trouver une alternative à GitKraken, partez de votre routine plutôt que d’une liste de fonctionnalités. Vous lisez un historique à plusieurs branches, vous préparez un commit, vous réécrivez parfois quelques commits avant de pousser, et vous travaillez sur les systèmes de votre équipe. Graphe, staging, rebase et plateformes sont les quatre critères que ce guide applique à tout client Git graphique, GitMini compris.

Une règle gouverne le tableau ci-dessous : une cellule ne contient que ce que sa source affirme. GitKraken Desktop est lu sur la page officielle du client GitKraken. Les autres outils viennent de l’annuaire des clients graphiques de git-scm.com, qui comptait 55 entrées au moment de notre lecture. Pour chaque entrée, il indique les plateformes, la licence et le coût, mais rien sur le graphe, le staging ou le rebase. « Non précisé » signifie donc que la source est muette, pas que la fonction est absente. Licence et coût sont volontairement exclus de cette comparaison : vérifiez-les sur le site de chaque outil.

Pour garder le tableau court, nous avons retenu deux entrées de l’annuaire aux plateformes différentes. Ne pas citer les autres n’est pas un jugement sur elles. Deux détails de plus sur la page de GitKraken, par souci d’exhaustivité : elle mentionne une vue des différences ainsi que des outils de fusion et de résolution de conflits, hors des quatre critères, et elle n’évoque le rebase que dans une phrase sur la composition de commits assistée par IA, sans décrire de rebase interactif. Pour le reste, consultez la documentation de GitKraken.

Ce qu’il faut regarder pour chaque critère :

• Graphe. Pouvez-vous lire plusieurs branches à la fois, repérer les merges, chercher dans l’historique et ouvrir le détail d’un commit ?
• Staging. Pouvez-vous indexer un fichier entier, un bloc de modifications (hunk) ou des lignes isolées ? Les outils diffèrent, et l’annuaire ne le dit pas.
• Rebase. Existe-t-il un rebase interactif avec réordonnancement, squash, reword et drop, et que se passe-t-il si la plage contient un commit de merge ?
• Plateformes. Quel système et quelle architecture de processeur, quel format de paquet, comment arrivent les mises à jour, et quelle version de Git l’outil exige-t-il.

Comparer les outils sur un même dépôt

Une page ne remplace pas dix minutes passées sur un dépôt. Construisez-en un jetable, avec des branches qui divergent, un merge et des modifications en cours, ouvrez-le dans chaque candidat, puis vérifiez le résultat avec Git plutôt qu’avec le client. Les commandes ci-dessous sont en Bash. Nous les avons exécutées avec Git 2.23 et 2.54 : aucune n’exige un Git récent (GitMini lui-même demande Git 2.30 ou plus). Lancez-les dans un dossier de travail vide.

mkdir client-trial
cd client-trial
git init
git checkout -b main
git config user.name "Example Dev"
git config user.email [email protected]
seq 1 40 > notes.txt
echo "# Client trial" > README.md
git add .
git commit -m "Add notes and README"
git checkout -b feature/search
echo "search: index" > search.txt
git add search.txt
git commit -m "Add search index"
echo "search: ranking" >> search.txt
git commit -am "Rank search results"
echo "search: tests" >> search.txt
git commit -am "Add search tests"
git checkout main
git checkout -b fix/pagination
echo "pagination: fix" > pagination.txt
git add pagination.txt
git commit -m "Fix pagination"
git checkout main
echo "release 0.1" >> README.md
git commit -am "Prepare release 0.1"
git merge --no-ff fix/pagination -m "Merge branch 'fix/pagination'"
git log --graph --oneline --all

La dernière commande affiche l’historique de référence. Vos identifiants seront différents, et l’ordre des lignes peut l’être aussi. Quand tous les commits tombent dans la même seconde, comme c’est le cas si vous collez tout le bloc, Git 2.23 affiche l’historique ci-dessous, alors que Git 2.30 et les versions suivantes (nous avons essayé les 2.30, 2.43 et 2.54) listent d’abord les trois commits de feature/search, au-dessus du merge. C’est le même historique dans les deux cas.

*   e4172e1 Merge branch 'fix/pagination'
|\
| * 003a193 Fix pagination
* | 25f5869 Prepare release 0.1
|/
| * ace3081 Add search tests
| * ce6bc7f Rank search results
| * 63a4b8d Add search index
|/
* 4bacbe3 Add notes and README

Ouvrez maintenant client-trial dans chaque outil et faites quatre vérifications.

1. Graphe. Comparez le graphe du client avec la sortie ci-dessus. Vous devez retrouver trois pointes de branche, un commit de merge et des voies parallèles. Sélectionnez un commit et regardez ce que l’outil affiche sur son auteur, sa date, ses parents et les fichiers modifiés.

2. Rebase. Basculez sur feature/search, puis utilisez le rebase interactif de l’outil pour fusionner « Add search tests » dans « Rank search results » (squash). Avant, git log --oneline main..feature/search liste trois commits. Après, il doit en lister deux.

   d66d2be Rank search results
   63a4b8d Add search index

3. Merge. Revenez sur main et fusionnez feature/search. Avant le merge, git branch --merged main ne liste que fix/pagination et main. Ensuite, il liste aussi feature/search.

     feature/search
     fix/pagination
   * main

4. Staging. Réécrivez deux lignes éloignées de notes.txt et ajoutez un fichier non suivi. Git voit deux hunks dans notes.txt, car les modifications sont assez éloignées l’une de l’autre.

   git checkout main
   seq 1 40 | sed '3s/.*/three/;38s/.*/thirty-eight/' > notes.txt
   echo "- write tests" > todo.txt
   git status --short

    M notes.txt
   ?? todo.txt

   Indexez uniquement la première modification dans l’outil. Un outil qui indexe par bloc le fait directement, les autres vous montrent ce qu’ils proposent à la place. Ensuite, git status --short doit afficher MM pour notes.txt, ce qui signifie que le fichier a des modifications indexées et d’autres qui ne le sont pas, et git diff --cached doit montrer un seul bloc @@.

   MM notes.txt
   ?? todo.txt

Dans GitMini, les mêmes étapes passent par ces entrées. Avec feature/search comme branche courante, faites un clic droit sur Rank search results et choisissez Interactive rebase from here…. Pour fusionner, faites un clic droit sur la branche feature/search dans la barre latérale et choisissez Merge “feature/search” in “main”. Pour le staging, ouvrez notes.txt depuis la liste Unstaged et cliquez sur Stage hunk sur le premier bloc. Notez aussi ce que fait chaque outil quand il ne peut pas réaliser une étape : un message clair, ou un contournement silencieux.

Ce que GitMini permet aujourd’hui

GitMini est un client Git de bureau construit avec Tauri, Svelte et Rust. Il lit les dépôts avec gix et exécute chaque modification par la CLI Git : c’est donc le Git installé sur votre machine qui écrit. Voici ce que l’arborescence source actuelle (version 0.1.0) et son README établissent.

• Graphe et historique. Un graphe des commits avec des colonnes pour les branches et tags, le message, l’auteur, la date et le SHA. Vous pouvez chercher par message, auteur ou SHA, lire les diffs et garder plusieurs dépôts ouverts dans des onglets.
• Staging et commits. Des listes Unstaged et Staged, avec Stage, Unstage, Stage hunk, Unstage hunk et Discard hunk, plus un formulaire de commit avec Amend the last commit. Le guide du staging et des commits détaille le parcours.
• Branches et réécriture de l’historique. Merge (fast-forward si possible, toujours un commit de merge, ou fast-forward seulement), rebase, cherry-pick, revert et stash. Le rebase interactif propose pick, reword, squash, fixup, drop et le réordonnancement par glisser-déposer : voyez le guide du rebase interactif.
• Remotes. Fetch, pull et push, et clonage ou ajout de remotes par URL.

Les limites à peser avant de choisir

• Pas de connexion GitHub. La connexion d’un compte GitHub est désactivée dans les builds actuels. Vous clonez et ajoutez des remotes par URL, et vous vous authentifiez avec des clés SSH ou un credential helper Git.
• Le staging s’arrête au bloc. Vous pouvez indexer, désindexer ou abandonner un fichier ou un bloc, mais pas des lignes isolées.
• Le rebase interactif a deux exclusions. Une plage qui contient des commits de merge n’est pas prise en charge dans cette première version, pas plus qu’un HEAD détaché.
• Les conflits se résolvent dans votre éditeur. GitMini liste les fichiers en conflit et propose Mark as resolved, mais la résolution elle-même se fait dans votre éditeur.
• Certains dépôts sont refusés. Les dépôts nus (bare), SHA-256 et reftable ne sont pas pris en charge.
• L’interface est en anglais. Tous les textes de l’application utilisent les catalogues anglais.
• Git 2.30 ou plus est requis et doit être accessible dans votre PATH.
• Les installateurs ne sont pas encore entièrement signés. Les premiers builds macOS utilisent une signature ad hoc et ne sont pas notarisés. Les installateurs Windows (.exe) n’ont, au départ, aucune signature Authenticode. Le README demande de vérifier le fichier SHA256SUMS de la release avant d’installer.
• Une liste courte de formats. DMG pour macOS (Apple Silicon ou Intel), .exe pour Windows, AppImage ou DEB pour Linux. Les builds Windows et Linux sont en x64.

Choisir et vérifier la distribution adaptée

Choisissez par élimination. Si vous avez besoin d’indexer des lignes isolées ou d’un éditeur de conflits intégré, vérifiez que votre candidat les propose, car GitMini n’offre ni l’un ni l’autre. Si un outil ne tourne pas sur un système utilisé par votre équipe, écartez-le. S’il en reste plusieurs, refaites l’essai ci-dessus sur votre propre dépôt.

Si GitMini vous convient, prenez le format de votre système. Les mises à jour automatiques utilisent une signature à part, distincte de la signature de code du système d’exploitation.

Les guides par système vont plus loin : client Git sous Linux, client Git pour macOS et client Git sous Windows. Avant d’installer quoi que ce soit, vérifiez Git et la somme de contrôle.

git --version

git version 2.43.0

Toute version à partir de 2.30 convient. Comparez ensuite le SHA-256 de votre fichier avec la ligne qui lui correspond dans le fichier SHA256SUMS publié avec la release. Vérifiez d’abord, puis suivez l’avis de première ouverture de votre système.

Sources

• Git : annuaire officiel des clients graphiques, consulté le 4 octobre 2026.
• GitKraken : page officielle du client, consulté le 4 octobre 2026.
• Documentation Git : git-gui, consulté le 4 octobre 2026.
• Documentation Git : gitk, consulté le 4 octobre 2026.
• README du produit GitMini, consulté le 4 octobre 2026.
• Documentation de release du produit GitMini (docs/releases.md), consulté le 4 octobre 2026.