Faut-il utiliser Git pour la documentation et la gestion de projet? Le code doit-il être dans un référentiel séparé?
Je démarre un référentiel Git pour un projet de groupe. Est-il judicieux de stocker des documents dans le même référentiel Git que le code - il semble que cela entre en conflit avec la nature du flux de révision git.
Voici un résumé de mes questions:
Le style de révision Git va-t-il être déroutant si le code et les documents sont archivés dans le même référentiel? Expériences avec cela?
Git est-il adapté au contrôle de révision de documentation?
Je suis PAS demandant si un système de contrôle des révisions en général devrait ou ne devrait pas être utilisé pour la documentation - il le devrait.
Merci pour les commentaires jusqu'à présent!
Nous stockons en permanence la documentation dans SVN. En fait, l'intégralité de notre manuel d'utilisation est écrit en LaTeX et stocké dans SVN. Nous avons choisi LaTeX spécifiquement parce qu'il s'agit d'un langage basé sur du texte et facile à afficher des différences ligne par ligne.
Nous stockons également certains fichiers au format non texte, comme les fichiers Microsoft Office .doc, les feuilles de calcul, les fichiers .zip, etc., si nécessaire ... mais certains des avantages d'un RCS sont perdus lorsque vous ne pouvez pas voir l'incrémentiel diffs.
L'essentiel est vraiment de s'assurer que votre documentation est bien organisée, afin que les gens puissent trouver (et mettre à jour) la documentation (et la source) quand ils en ont besoin.
Eh bien, cela dépend du format que vous utilisez pour la documentation. Si c'est quelque chose basé sur du texte, tout va bien.
Git peut également stocker du contenu binaire et vous pouvez suivre les révisions, mais la sortie diff n'aura aucun sens.
Il est également possible de stocker la documentation dans le code lui-même, comme pod perldoc, Java a également un certain format/annotation pour cela.
Je ne peux pas imaginer pourquoi vous pensez qu'il pourrait y avoir un problème en utilisant git, ou tout autre système de contrôle de version, pour la documentation. Tout comme le code source, la documentation doit avoir un historique complet et la possibilité de revenir à une version antérieure si cela devient nécessaire. Un système de contrôle de version est parfait pour cela.
Il est clair que l'utilisation d'une sorte de système de contrôle de version pour stocker des documents est un nobrainer. La partie la plus intéressante de la question est de savoir si c'est une bonne idée de stocker des documents dans le MÊME emplacement que le code source? Le problème possible ici est qu'il peut être difficile de définir des privilèges d'accès différents pour le code et la documentation dans ce cas. Et dans de nombreux cas commerciaux, les gens auront besoin d'accéder aux documents, mais pas au code source, comme les départements marketing ou BA.
Dans l'entreprise dans laquelle je travaille, nous mettons la documentation en SVN. Cependant, après quelques conflits et la nécessité de le partager, nous avons décidé de le déplacer vers Mediawiki.
Au début, c'était Trac, puis il a été transféré vers Mediawiki car il était plus facile à utiliser ...
Le principal problème avec SVN était la cause du partage, nous avions un système d'autorisation pour SVN.
Je suis venu ici avec une question similaire. Nous venons d'un environnement SVN, où il est fondamentalement évident de garder tous les matériaux liés à un projet dans le même référentiel. En raison de la nature de SVN, vous pouvez facilement consulter des parties du référentiel, donc si vous avez juste besoin du code source (par exemple, un déploiement de site Web), ce n'est pas un problème.
Avec Git, les choses sont différentes. Une extraction est toujours au niveau racine, donc si vous voulez tout mettre dans le même référentiel, vous vous retrouverez toujours avec la même structure de répertoires. Une approche que j'ai rencontrée consiste à tout mettre dans des branches distinctes, c'est-à-dire que vous avez des branches de code (qui seraient généralement vos branches master, develop, etc.) et une branche doc, qui a sa propre structure de répertoires distincte. Je ne suis pas encore certain que ce soit la meilleure idée, mais c'est une suggestion qui contourne le problème qui, j'imagine, est à la base de votre question.
J'utilise un wiki pour les documents internes ... obtenez la révision PLUS un accès proéminent/une édition facile. Lorsque la documentation n'est pas synchronisée, mettez-la à jour sur-le-champ. Pour la documentation destinée aux utilisateurs finaux, envisagez un outil professionnel comme Madcap Flare Ils utilisent un dialecte XML pour partager, composer et transformer la documentation.