Fork, un client git gratuit pour macOS et Windows

Article publié sur : https://www.geekzone.fr/2019/09/10/fork-un-client-git-gratuit-pour-macos-et-windows/
Le marché ne manque clairement pas de clients git pour se connecter sur des outils comme GitHub, GitLab ou encore Bitbucket. Mais des gratuits, rapides, et avec une interface qui ne donne pas envie de se sauver ? C’est déjà plus rare et c’est pour ça qu’on parle de Fork aujourd’hui ! Commençons par l’évidence : Fork, c’est le meilleur…

3 J'aimes

Je suis passé à Fork après en avoir eu marre de SourceTree (compte Bitbucket obligatoire, interface qui parfois bug, etc.), je ne regrette rien. Le client est extra, complet, et surtout les devs sont à l’écoute (feature implémentée en 5 jours à ma demande par exemple.

2 J'aimes

Ah, ça pourrait etre une bonne alternative à GitKraken qui me fatigue à essayer de me faire payer

1 J'aime

Je connaissais mais je vois qu’il a bien évolué…

Légère disgression. Ce qui m’intéresse dans ce genre d’outil, c’est de constater ces nouveaux usages de git : de plus en plus d’utilisateurs hors du cercle des « développeurs » purs et durs sont amenés à utiliser des outils de contrôle de code source (ou plutôt de fichier) (coucou caf ?).

De plus en plus de projets qui ne sont pas du code utilisent ces outils : gestion de configurations, bases documentaires, sites statiques, etc. La raison est assez simple : la fonction de gestion de fichiers avec versions et partageable. Le genre de fonctionnalité qu’aucun outil n’a réussi à proposer facilement sur aucun OS (y’a qu’à voir dropbox qui est en train de faire des protypes en remplaçant le driver fichier pour une UI proprio)

Du coup on découvre de nouveaux utilisateurs qui on besoin d’utiliser l’outil (GIT) sans rien y connaître ni y comprendre. Et donc des outils pour interagir avec sans devoir se bruler les ailes.

La tâche est énorme, surtout lorsque l’on sait à quel point GIT est complexe et que les problématiques de conflits restent par nature difficiles à resoudre d’un coup de baguette magique.

Je cherche encore un client simple pour le déployer à mes utilisateurs (qui sont de simples utilisateurs) pour qu’ils puissent interagir avec une base documentaire en markdown. Pour l’instant ils utilisent les fonctions d’édition directes des fichiers en ligne (de github et gitlab par exemple), voir VS Code pour certains (encore trop complexe pour tous).

Sauf que si un client git cherche à couvrir toutes les fonctionnalités de la ligne de commande, il perdra forcément cette simplicité d’utilisation nécessaire pour rejoindre la liste des outils qui cherchent à tout faire via leur UI…

Tout dépend de la cible du soft, mais je pense qu’il y aura de plus en plus de cibles pour un client Git simple, ne couvrant pas toutes les fonctionnalités mais se focalisant sur la facilité d’accès.

Dans la liste, j’ai uniquement trouvé GitHub desktop qui mise principalement sur l’accessibilité.

Fork semble avoir une excellente UX, pas sur qu’il puisse être le client que je cherche pour ma problématique, mais il remplacera peut-être sourcetree qui me saoule aussi.

4 J'aimes

De plus en plus de teams utilisent ça pour écrire, surtout qu’il existe d’excellents softs même sur iOS maintenant, cf :

Trop de softs perdent du temps à proposer des trucs de mise en page qui ne serviront à rien après un export pour publication Web par exemple…

1 J'aime

J’utilisais GitKraken avant pour certaines actions, notamment parce que le côté visuel était parfois plus facile que la ligne de commande que j’utilise à 90%. Cependant Fork m’a bien plu.

  • Pas de compte chiant à associer au logiciel
  • Beaucoup plus léger (déjà parce que c’est pas une app sous Chronium…)

Pour rebondir sur le reste de la discussion, pour un projet de base de karaokés collaboratif j’ai initié des gens non informaticiens à l’utilisation de git, et ils trouvent ça bien mieux que de gérer nos fichiers de travail par un nextcloud par exemple. C’est bien plus sécurisant pour eux les commits, même si Git a encore des progrès à faire.

Je vais pas trop cracher sur Gitkraken car sans lui ils n’auraient certainement pas fait l’effort de s’intéresser à Git.

Du coup on utilise Git pour le code de l’app mais aussi pour le code des sites web (documentation, site vitrine sous Jekyll, etc.) mais aussi pour des fichiers non « code » comme la base de karaokés. Je me permets de lâcher un lien :

Ca a familiarisé tout le monde avec les commits, mais aussi les issues et les pipelines de CI/CD et tout le monde y trouve son compte niveau organisation.

3 J'aimes

Impressionné d’avoir pu faire utiliser un tel logiciel à des non développeurs. Je suis en train de parcourir votre repo. Pour moi la partie la plus importante est la doc.

De notre côté j’ai voulu proposer d’utiliser git pour un projet de traduction collaborative des règles d’un jeu de rôles (pathfinder 2nd édition). Nous avions utilisé un wiki pour la première édition, mais le soft n’est plus maintenu et je voulais partir sur une base plus pérenne (donc des fichiers markdown). J’avais commencé à écrire une documentation pour les contributeurs néophytes, qui est restée inachevée pour l’instant.

Je me suis tout de même retrouvé à devoir prendre la main sur le PC d’un contributeur pour lui résoudre un conflit de merge…

Pour le markdown je leur ai fait découvrir Ghostwriter https://wereturtle.github.io/ghostwriter/ qui rend l’écriture un peu plus comme un traitement de texte.

Pour la doc on utilise Mkdocs pour construire le site de docs sur http://docs.karaokes.moe

Après je te rassure tout le monde n’a pas adhéré non plus, mais une bonne partie des gens a trouvé le principe sympa, le tout était de faire de la bonne documentation. Ensuite les gens se sont entraidés pour montrer aux autres comment ça marchait.

Mais y’a un vrai manque pour rendre git accessible. Gitkraken fait ça plutôt bien même si il est lourdingue. Fork c’est pas complètement ça mais ça va dans une bonne direction.

C’est super intéressant votre discussion car j’ai exactement la même problématique. Des gens me demandent des sites qu’ils éditent peu/pas ou de manière peu complexe. Un site statique suffit mais comment faire en sorte qu’ils mettent à jour en poussant leurs fichiers ? C’est super compliqué.

Une des solutions c’est l’utilisation d’un CMS statique (avec ou sans front associé) avec tous les bénéfices que ça offre (notamment un back office avec éditeur) dont les changements sont transmis à un repo git. Kirby proposait cette solution via un plugin mais globalement cela doit être faisable d’automatiser ça.

Je me demande si ça va rester gratuit longtemps…

Mais non, ne soit pas pessimiste… Quoique… Quand je vois « free » & « basic features » j’ai peur que tu puisses avoir (un peu) raison.

Je vais tester, mais pour le moment je n’ai trouvé aucun client Git qui arrive à la cheville de ce qui est intégré à Jetbrains IntelliJ IDEA, même en version gratuite. Il ne donne pas forcément accès à toutes les fonctionnalités de Git, mais la facilité des merges (la baguette magique à merge, meilleure fonctionnalité du monde), la possibilité de faire des commits dans plusieurs repos simultanément, tout ça le rend quasi miraculeux. J’en suis même à éditer des fichiers texte avec cet éditeur juste pour profiter du client git, malgré l’overkill total que c’est.

1 J'aime

Ça ne répond probablement pas totalement au besoin, mais beaucoup de softs de repos git intègrent désormais des éditeurs de texte avec parfois même une prévisualisation du résultat en markdown.

This. Bordel this.

Et dans la dernière version en EAC, tu peux enfin pousser des branches sans faire un checkout. Enfin.

1 J'aime

Qu’est-ce que ça fait exactement ?

Lors d’un merge, s’il y a un conflit entre deux versions d’un même fichier, sur l’écran de diff du fichier, ça permet de résoudre 99% des lignes en conflit mieux qu’un humain. De temps en temps il se loupe, donc ça ne dispense pas de revérifier après avoir cliqué ce bouton, mais il se trompe quand même beaucoup moins qu’un humain.
Je n’ai aucune idée de comment il procède, mais ça marche bigrement bien.

1 J'aime

Thanks, je checkerai ça la prochaine fois, je touche plus trop au code mais ca m’arrive de faire des rebase et de tomber sur des merge que je dois résoudre à la mano et je n’avais jamais fait attention à cette fonctionnalité :heart_eyes:

Le merge auto en cas de conflit c’est quand même un peu la roulette.

Idem, j’ai toujours un gros doute. Pour le moment je reste sur BeyondCompare pour mes merge. Il est supporté en tant qu’outil externe dans toutes les UI git que j’ai testé.