URL: https://linuxfr.org/news/sortie-de-gitblit-1-4-x Title: Sortie de Gitblit 1.4.x Authors: Johann Ollivier-Lapeyre Davy Defaud, BAud, palm123, olivierweb, claudex et NeoX Date: 2014年03月20日T10:25:21+01:00 License: CC By-SA Tags: forge, git, gitblit et forge_logicielle Score: 31 Gitblit est un outil de gestion de dépôt Git, à l’instar de Gitosis ou Gitolite. L’idée est de permettre de partager ses dépôts, gérer des droits d'accès, fournir des sauvegardes... tout en restant dans les murs de l’entreprise si nécessaire. Pour les entreprises, justement, qui n’ont pas toujours de compétences Rails ou de culture des clefs SSH, Gitblit possède certains atouts. Au niveau administration, avec une application légère en Java, autonome ou hébergeable dans un Tomcat ou dans le Cloud. Au niveau de la gestion des utilisateurs, Gitblit offre, au choix, des solutions généralement appréciées des entreprises : LDAP ou Active directory avec gestion des habilitations basée sur les groupes, Windows, [PAM](http://fr.wikipedia.org/wiki/Pluggable_Authentication_Modules), Conteneur type Tomcat ou personnalisé. La gestion par clefs SSH sera apportée par la version 1.5. Associé aux autres fonctionnalités plus courantes, Gitblit offre la possibilité de mettre en place un _Github-like_ dans son entreprise. ---- [Site officiel](http://www.gitblit.com/) [Demo de la prochaine version](https://next-gitblit.rhcloud.com/) [Fork Github pour la traduction française](https://github.com/johannol/gitblit) [Screencast de fonctionnalités liées aux Tickets](http://vimeo.com/86164723) ---- # Fonctionnalités précédentes # ## Gestion des Hooks ## Un mécanisme de _Hook_ (ou _Trigger_) est accessible, permettant de scripter des actions lors d’un _push_. Ils se programment en Groovy et ont accès au cœur de l’application. Quelques lignes suffisent donc pour créer une interaction avec une intégration continue ou une gestion de ticket. Des exemples utilisables sont fournis, entre autres, avec Jenkins ou Redmine. Un aspect intéressant, c’est qu’il est possible de définir des _Hooks_ systématiquement exécutés (comme avec Subversion) pour une intégration avec Jenkins, mais également des _Hooks_ activables à la demande et par projet dans l’interface. C’est le chef de projet qui choisit la gestion de tickets utilisée sur ce projet. ## Fédération et réplication ## Un système complet de fédération de serveurs est utilisable. Les objectifs possibles peuvent être, par exemple, d’avoir un miroir permanent sur un autre site afin de permettre une reprise d’activité rapide en cas d’incident (PRA). Ou, autre cas d’entreprise pour les grosses structures, d’avoir un dépôt dans chaque site ou ville, consolidé au niveau national. ## Divers ## Quelques autres fonctionnalités intéressantes : * possibilité de n’être qu’un simple visionneur de dépôt d’un autre service Git, comme Gitolite avec SSH, ou Gerrit ; * une indexation Lucene pour faire des recherches performantes sur un ensemble de dépôts ; * des menus personnalisables pour les clients Git utilisables dans l’entreprise ; * une API JSON-RPC, qui sera d’ailleurs largement complétée avec la version 1.5, afin de permettre des _workflows_ avancés, comme des acceptations partielles par Jenkins de _pull-request_. # Nouveautés majeures apportées par la version 1.4.x # ## Tickets ## Une gestion de Tickets similaire à GitHub/BitBucket a été implémentée mais un peu différemment. Il n’y a pas de distinction entre un ticket et un _pull request_. Chaque ticket peut avoir un ou plusieurs _commit(s)_ lié(s) à une branche et il n’y a pas nécessité de créer plusieurs tickets pour différentes versions (_forks_) du même code. Au niveau de Gitblit, la conception tourne autour de quelques principes : * gestion simple pour tracer les actions ou les rapports d’utilisateurs ; * chaque ticket peut contenir des _commits_ partagés par un contributeur ; * le ticket doit être la source canonique de _commits_ lié au ticket (et non les _commits_ d’un _fork_) ; * les contributeurs supplémentaires d’un problème doivent pouvoir développer des ensembles de _patches_ pour un ticket, et non seulement le créateur du ticket. Le ticket rassemble donc l’ensemble des contributions et non seulement une revue de code ; * pas de perte d’historique entre le mainteneur ou contributeurs. Gitblit a pris son inspiration depuis GitHub, BitBucket, and Gerrit. Les différents mécanismes techniques sous‐jacents ont été implémentés et testés avant de faire les choix définitifs. ## Workflow de collaboration (pull-request) ## Les _pull requests_ à la manière de GitHub demandent le _workflow_ suivant : * _forker_ le ProjetA en MonProjetA ; * cloner MonProjetA sur le poste de travail ; * créer MonProjetA_Clone:topic_branch et travailler sur la contribution ; * faire un _push_ MonProjetA_Clone:topic_branch upstream vers `MonProjetA:topic_branch` ; * Ouvrir une _pull request_ depuis MonProjetA:topic_branch vers `ProjetA:integration_branch` ; * Le propriétaire de ProjetA fait un _pull_ `MonProjetA:topic_branch` vers `ProjetA:integration_branch` et inspecte la contribution ; * Le propriétaire de ProjetA fait enfin un _push_ de la contribution fusionnée vers `ProjetA:integration_branch`. Le flux avec Gitblit ressemble à ceci : * cloner ProjetA ; * créer `ProjetA_Clone:topic_branch` et travailler sur la contribution ; * faire un _push_ `ProjetA_Clone:topic_branch upstream` vers `ProjetA:refs/for/[new|id]` , * le propriétaire de ProjetA fait un _fetch_ et un _merge_ de la branche ticket/[id] ; * le propriétaire de ProjetA fait un _push_ de la fusion vers `ProjetA:integration_branch`. Le workflow Gitblit supprime la conception à 4 dépôts de Github (canonique, copie de travail canonique, fork, & copie de travail du fork) au profit d'une à 3 dépôts (canonique, copie de travail canonique, copie de travail du clone). La conséquence de l’implémentation de Gitblit, c’est que pour le travail d’une nouvelle fonctionnalité donnée, il y a harmonie entre un ticket, les _commits_ dans une branche liée, la contribution à plusieurs sur cette branche, les revues de code (avec notes) et la fusion. Au passage, on économise les ressources système d’un dépôt supplémentaire et d’une étape dans l’interface Web. # Licence et Contribution # Gitblit est sous licence Apache 2.0 et est développé pour l’instant sur Github. Les contributions sont appréciées, via le mécanisme du _fork_ et _pull-request_. Une traduction en français de l’interface est commencée sur le _fork_ listé dans les liens, n’hésitez pas à y contribuer. L’objectif premier est d’avoir une traduction gardant le nom des commandes Git intact et, peut‐être ensuite, une autre plus « québécoise » traduisant intégralement tous les termes. Les gens choisiront.

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