URL: https://linuxfr.org/users/ife/journaux/pourquoi-github-saimal-quelques-alternatives Title: Pourquoi GitHub saimal, quelques alternatives Authors: Ife Date: 2012年12月08日T19:35:02+01:00 License: CC By-SA Tags: github, git, gitlab, troll, gitorious, alternatives et linus_torvalds Score: 24 Cher journal, Je sais que trolldi était hier, mais je n'ai pas eu le temps d'écrire ceci et je n'ai pas envie d'attendre une semaine. # Github Je pense que tu connais [GitHub](https://github.com/) pour partager ton code. Si ce n'est pas le cas, il s'agit juste d'une plateforme externe sur laquelle on peut démarrer un projet et héberger son code. Pour chaque projet, github fournit un bugtracker et un wiki. Github suit le workflow décentralisé de git, on peut forker un projet (comme si on faisait un `git clone`), et faire une « Pull Request » (soumettre ses modifications au projet qu'on a forké) Je t'écris donc pour te signaler que de plus en plus de personnes utilisent github pour héberger leur code, malheureusement je pense que ce ne soit pas une bonne solution. La première chose à savoir est qu'il y a deux modèles économiques pour les logiciels en tant que service (ce que fait github, il fournit un dépôt git, un wiki et un bugtracker en tant que service). Je reconnais que la frontière entre les deux est souvent floue : * Le modèle propriétaire : le code du service n'est pas fourni, il est très difficile voire impossible d'exporter les données. Le fournisseur de service mise sur la dépendance du client au service. * Le modèle libre : le code du service est fourni, il est souvent possible d'exporter ses données facilement. Les fournisseurs de service misent sur la qualité de service et les clients qui n'ont pas la compétence en interne pour installer ce service. Les fournisseurs peuvent aussi faire payer l'ajout de fonctionnalités. GitHub est dans cette frontière floue entre les deux, mais beaucoup plus du côté propriétaire. Les [parties les moins importantes de leur service](https://github.com/github) sont libres, par exemple [Gollum](https://github.com/github/gollum) leur moteur de wiki utilisant un dépôt git. Mais le cœur de l'application est entièrement propriétaire. Qui plus est, le [site a des conditions d'utilisation](http://tos-dr.info/#github) douteuses : * Votre compte utilisateur peut être suspendu et vos données supprimées à n'importe quel moment si github en a envie. Veillez donc à avoir un clone de votre code et wiki dans un coin si nécessaire. (Pour votre bugtracker... bein vous êtes baisé). * Pas d'anonymat sur github, github vous demande votre vrai nom. [À l'heure où j'écris ce journal](http://github.com/site/terms) (car oui, github se réserve le droit de changer les conditions d'utilisation à leur bon vouloir) :> A. Account Terms> [...]> 3. You must provide your legal full name, a valid email address, and any other information requested in order to complete the signup process.> [...]> D. Cancellation and Termination> [...]> 4. GitHub, in its sole discretion, has the right to suspend or terminate your account and refuse any and all current or future use of the Service, or any other GitHub service, for any reason at any time. Alors oui bien sûr, tu te dis « encore un trolleur qui me dit ce que je dois pas faire, alors qu'il y connaît rien, ne propose aucune solution. » Tu penses « github me fournit un wiki, un bugtracker et n'est jamais down ». Déjà, ces derniers temps github est de plus en plus hors-service. Ça va, vu que les développeur open-source utilisent le service gratuitement, mais si je faisais parti de ceux qui payent pour ça, je ne serais pas très content... J'utilise personnellement la méthode Linus Torvalds avec un gitweb autohébergé (je détaille après). # La méthode Linus Torvalds À mon avis, Linus Torvalds, le créateur de Git (et d'un autre [petit projet aussi](http://subsurface.hohndel.org/) ), est le mieux placé pour savoir comment utiliser Git. Je vous conseille son [Google Talk sur Git](https://youtu.be/4XpnKHJAok8) (marche sans Flash et sans H.264 chez moi) qui explique plusieurs concepts sur les workflows sous git, etc. Lors de [l'attaque des serveurs de kernel.org](http://linuxfr.org/news/les-serveurs-de-kernelorg-ont-%C3%A9t%C3%A9-compromis), Linus Torvalds est passé sous github. [Comme il l'a expliqué](https://github.com/torvalds/linux/pull/17), il n'utilise github que comme hébergeur git, selon lui c'est une très mauvaise interface et il casse le workflow de git. Linus Torvalds utilise la [Linux Kernel Mailing List](http://lkml.org/) comme Wiki, Bugtracker et pour la soumission de patch. Git inclut plusieurs « sous-modules », pour gérer la soumission de patch par email. L'email a plusieurs intérêts : * Pas besoin de se logguer plusieurs fois (avec github, vous recevez un mail disant « il faut appliquer le patch/pull request, cliquez sur ce lien », puis vous devez vous logguer sur github) * Une fois le patch reçu par mail, il peut être appliqué hors-ligne, localement (avec github, vous validez la pull request, il faut ensuite que vous fassiez un `git pull`, pour avoir les modifications en local) * Si vous utilisez Mutt ou Emacs, vous n'avez pas besoin de quitter la ligne de commande. De plus, (je ne sais pas si c'est toujours le cas maintenant), mais pour un patch d'un commit ou pour un merge qui peut être rebasé, github fait un commit de merge quoi qu'il arrive... Si vous ne les connaissez pas, voici les commandes git pour gérer l'application/envoi de patch/pull request par email : * [`git am`](http://git-scm.com/docs/git-am) pour appliquer des patch depuis votre boîte mail. * [`git apply`](http://git-scm.com/docs/git-apply) pour appliquer un patch depuis un fichier ou l'entrée standard. * [`git format-patch`](http://git-scm.com/docs/git-format-patch) pour créer un ou une série de patches. * [`git send-mail`](http://git-scm.com/docs/git-send-email) pour envoyer un patch ou une « Pull Request » par email. * [`git request-pull`](http://git-scm.com/docs/git-request-pull) pour générer une « Pull Request » par mail. # Alternatives externalisées Il existe plusieurs alternatives à github, dont le code est libre. M'auto-hébergant, je n'ai testé aucun de ses services, si quelqu'un a des retours, je suis tout ouïe. J'ai eu des bon retours sur gitorious et repo.or.cz, c'est pour ça que je les ai mis en premier. ## [repo.or.cz](http://repo.or.cz/) C'est le meilleur service à utiliser en combinaison avec ce que j'appelle « la méthode Linus Torvalds », il fournit juste un hébergement git. C'est tout (ce pourquoi Linus Torvalds utilisait github). Comme indiqué sur la page d'accueil, [le projet est entièrement open-source](http://repo.or.cz/w/girocco.git). C'est un peu un gitweb amélioré. Les conditions d'utilisations sont « vous utilisez git qui est décentralisé, donc on ne fait pas de backup, car notre backup c'est votre copie locale ». Mais ça reste bien pour partager un dépôt git. ## [Gitorious](http://gitorious.org/) C'est le clone libre de github. On m'a dit que par rapport à github, il y avait certaines lacunes. Je ne sais pas lesquelles. Si des gens ont des avis/retours là dessus, n'hésitez pas à partager. Je n'utilise ni l'un ni l'autre, donc je ne peux pas dire. Contrairement à repo.or.cz, c'est une entreprise qui est derrière (et non pas une bande de potes comme repo.or.cz), ils ont un « business model » basé sur le logiciel libre : – [le code de leur service est open-source](http://gitorious.org/gitorious), sous AGPLv3 (RMS serait content) ; – [ils vendent](http://gitorious.com/local_install/) de la qualité de service, des installations locales, du consulting... ## [Savannah](http://savannah.gnu.org/) Contrairement à repo.or.cz et gitourious qui hébergent n'importe quel projet sous licence libre. Il semblerait que GNU Savanah n'héberge que des logiciels qui tournent sur les système d'exploitation libres (si votre projet ne tourne que sous Windows, je ne suis pas sûr que ça passe). Ils supportent plein de gestionnaires de code : de git à CVS (malheureusement des gens l'utilisent encore). Comme tout projet GNU, il est [libre](http://savannah.nongnu.org/projects/savane-cleanup). # Alternatives auto-hébergées Bien sûr, toutes les alternatives ci-dessus peuvent être auto hébergées. Mais voici quelques pistes selon vos besoins : ## SSH Il suffit juste d'installer SSH et git sur votre serveur. Et c'est bon. ```sh [moi@mamachine ~]$ ssh monserver [moi@monserveur ~]$ git init --bare /srv/git/projet.git [moi@monserveur ~]$ exit [moi@mamachine ~]$ git clone ssh+git://monserver/srv/git/projet.git/ [moi@mamachine ~]$ cd projet [moi@mamachine ~/projet]$ touch README [moi@mamachine ~/projet]$ git add README [moi@mamachine ~/projet]$ git commit -v -m "Initial commit" [moi@mamachine ~/projet]$ git push origin ``` Tanguy explique [comment gérer plusieurs utilisateurs](http://linuxfr.org/forums/linuxdebianubuntu/posts/comment-cr%C3%A9er-un-repo-git-centralis%C3%A9#comment-1278456). ## Fichiers statiques HTTP Si vous voulez juste publier les fichiers contenus dans votre « .git » avec votre serveur HTTP favori. La personne qui veut cloner votre dépôt n'aurait juste qu'à faire `git clone http://example.net/projet.git`. ## [git-daemon](http://git-scm.com/book/en/Git-on-the-Server-Git-Daemon) Le git-daemon est un sous-module de git, qui permet d'utiliser le protocole git. Il ne permet que la lecture seule. ## gitweb Il s'agit de l'interface web fournie avec git. C'est un gros script CGI en perl. Ça fournit toutes les fonctionnalités de git demandées. Il devra être utilisé soit en association avec les fichiers statiques en HTTP, soit avec git-daemon, pour pouvoir directement faire un `git clone`. ## [gitolite](http://sitaramc.github.com/gitolite/) Il s'agit d'un script perl qui permet de gérer l'authentification et l'autorisation sur des dépôts git, par SSH, le tout avec un seul utilisateur unix. ## [GitLab](http://gitlabhq.com/) C'est un clone libre de [Github Enterprise](https://enterprise.github.com/), c'est pour ça qu'à l'heure où j'écris ce journal il ne gère pas les dépôts publiques. Il demande une authentification pour accéder au site. ## [cgit](http://hjemli.net/git/cgit/) C'est une alternative à gitweb, il est utilisé par [freedesktop](http://cgit.freedesktop.org/). À l'heure où j'écris, il assez mal codé (il est statiquement lié à git, c'est pour ça que [debian ne veut pas le packager](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515793)). # Interface graphiques Je dois reconnaitre que j'aime bien avoir une interface graphique pour visualiser l'historique/les modifications de mon projet git. J'aime bien gitweb pour ça, mais c'est vraiment une question d'habitude. Depuis quelques temps, je suis passé à [gitg](http://freecode.com/projects/gitg) qui a l'avantage d'être hors-ligne (donc plus rapide). Pour ceux qui voudraient troller en disant « tu ne peux pas utiliser git en ligne de commande ?! », je le préfère pour la visualisation et navigation de l'historique, les branches et merges sont plus lisibles qu'avec `git log --graph` et il permet d'accéder à un commit référencé dans un autre avec un simple clic. [QGit](http://sourceforge.net/projects/qgit/) fait la même chose avec Qt (peut-être avec plus de fonctionnalités, mais gitg me suffit). ---------------- Bien sûr, je trolle à propos de github, mais c'est la même chose pour [Bitbucket](https://bitbucket.org/) avec git et Mercurial. Il existe [RhodeCode](http://rhodecode.org/) comme alternative à Bitbucket auto-hébergé. Sinon le wiki de Mercurial [a un article dédié](http://mercurial.selenic.com/wiki/PublishingRepositories), il s'y connaît beaucoup plus que moi. Quant à [Fossil](http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki), il a tout d'intégré. Et pour [Bazaar](http://bazaar.canonical.com/en/), [Launchpad](https://launchpad.net/) a été [libéré](https://dev.launchpad.net/Getting), mais je ne connais pas trop les conditions d'utilisation du service en lui-même et la possibilité d'export de données... Un texte long comme ça n'est pas sans fautes d'orthographe, à vous les *gramar nazis*.

AltStyle によって変換されたページ (->オリジナル) /