Si je saisis bien le fonctionnement de cet outil pour la gestion des tickets:
Lorsque l'on contribue à un projet en le "forkant", on pushe vers le dépôt de référence et c'est une convention de nommage qui permet d'isoler chaque contributeur, là où le fork de Github crée un clone à la volée sur le serveur.
Ensuite pour l'acceptation, l'intégrateur se contente de merger cette branche en local et de pusher sur la branche d référence.
Le dépôt de référence est donc suceptible d'être pollué par d'autres branches ce qui va à l'encontre de la philosophie du "pull request".
Pour ce qui est des fonctionnalité, hormis l'interface de gestion de ticket je préfère nettement SCM Manager
( http://www.scm-manager.org/ ) qui est très comparable en terme de fonctionnalité pour un gestionnaire de dépôt (full Java, integration LDAP, ...)
Nous l'utilisons depuis 1 an et demi dans notre entreprise (une DSI). Il héberge plus de 800 dépôts et s'intègre très bien avec le reste de notre forge basée sur la suite Atlassian (JIRA/Bamboo/Crowd). Un plugin d'intégration à Crowd est fourni (annuaire Atlassian qui lui même référence l'annuaire AD de l'entreprise).
Il est maintenant très stable et supporte par ailleurs les pull request à la manière de Github et donc de façon cloisonnée.
Le seul inconvénient.
Dans JIRA les commits d'un ticket sont référencés dans l'onglet description alors que SCM Manager ne peut les afficher qu'en tant que commentaire. Mais c'est plutôt une limitation de JIRA que de SCM Manager.
# Petite revue
Posté par El Titi . En réponse à la dépêche Sortie de Gitblit 1.4.x. Évalué à 3.
Si je saisis bien le fonctionnement de cet outil pour la gestion des tickets:
Lorsque l'on contribue à un projet en le "forkant", on pushe vers le dépôt de référence et c'est une convention de nommage qui permet d'isoler chaque contributeur, là où le fork de Github crée un clone à la volée sur le serveur.
Ensuite pour l'acceptation, l'intégrateur se contente de merger cette branche en local et de pusher sur la branche d référence.
Le dépôt de référence est donc suceptible d'être pollué par d'autres branches ce qui va à l'encontre de la philosophie du "pull request".
Pour ce qui est des fonctionnalité, hormis l'interface de gestion de ticket je préfère nettement SCM Manager
( http://www.scm-manager.org/ ) qui est très comparable en terme de fonctionnalité pour un gestionnaire de dépôt (full Java, integration LDAP, ...)
Nous l'utilisons depuis 1 an et demi dans notre entreprise (une DSI). Il héberge plus de 800 dépôts et s'intègre très bien avec le reste de notre forge basée sur la suite Atlassian (JIRA/Bamboo/Crowd). Un plugin d'intégration à Crowd est fourni (annuaire Atlassian qui lui même référence l'annuaire AD de l'entreprise).
Il est maintenant très stable et supporte par ailleurs les pull request à la manière de Github et donc de façon cloisonnée.
Le seul inconvénient.
Dans JIRA les commits d'un ticket sont référencés dans l'onglet description alors que SCM Manager ne peut les afficher qu'en tant que commentaire. Mais c'est plutôt une limitation de JIRA que de SCM Manager.