git commit ensemble différent de fichiers pour développer et maître

Question

J'ai récemment commencé à développer une nouvelle bibliothèque, et utiliser Git pour le contrôle de révision. J'ai décidé de suivre l'article de blog extrêmement populaire A successful Git branching model pour gérer les branchements. Il est temps pour moi de faire ma première version, et j'aimerais avoir des conseils sur la gestion de certains ensembles de fichiers, comme je le décris ci-dessous. Sur les branches de développement de branche et d'entité, je veux tous les "fichiers de support", tels que le fichier makefile utilisé pour la compilation et le fichier readme.md utilisé par doxygen pour générer de la documentation. (Notez que ce ne sont que quelques exemples.J'ai beaucoup plus de "fichiers de soutien".)

Le billet de blog dit aussi qu'une validation à la branche maître est une version par définition. Je veux que la version inclue tous les "fichiers binaires" (qui incluent, par exemple, les fichiers objets résultant de la compilation et les fichiers html contenant la documentation). Ces fichiers doivent être validés dans la branche master afin que les clients puissent simplement cloner à partir du référentiel avec la balise et obtenir la version requise.

Je préfère ne pas avoir les « fichiers de support » dans la version (car je ne veux pas donner aux clients des tas de fichiers, ils ne veulent pas ou ne peuvent pas utiliser). De même, je préfère ne pas avoir les «fichiers binaires» contrôlés par la version dans les branches de développement et de fonctionnalité. Ainsi, je veux commettre un ensemble de fichiers à développer, et un autre ensemble de fichiers à maîtriser. (Bien sûr, il y a aussi un ensemble de fichiers qui sont «communs» aux deux branches.) Cependant, je suis sceptique quant à la désynchronisation du maître et au développement des branches comme cela vient d'être décrit.

Le modèle que je propose est-il bon? Si oui, comment devrais-je faire face à l'engagement de différents fichiers à développer et à maîtriser? Y a-t-il une meilleure façon de gérer cette situation?

Je suis passé par chacun des commentaires sur cette page de blog, des recherches sur Internet, et également recherché ici sur StackOverflow. A partir des résultats de recherche, ce post GIT repositories with some different files semble être le seul à être proche de ma question. Aucun de ceux-ci m'a aidé à comprendre la solution.

Answer 1

IMO la solution proposée n'est pas bonne. Une solution commune à votre problème est:

• contrôle de version tous les "fichiers de prise en charge". Si vous vous souciez si ces fichiers sont modifiés ou supprimés alors ils devraient être sous contrôle de version
• ne contrôle pas de version « fichiers binaires, » si elles sont simplement générés par le processus de compilation. Le code qui est compilé et les Makefiles sont ce qui compte. Vous pouvez éventuellement avoir des fichiers binaires dans un dossier 'bin' s'ils sont utilisés pour compiler le code.
• créer un processus de construction autour du package que vous souhaitez remettre au client. Vous pouvez soit créer un paquet pour le client auquel ils peuvent accéder, ou vous pouvez les faire exécuter votre "script de paquet" eux-mêmes. Le "script de paquet" peut cloner le repo, construire le paquet, et supprimer le repo juste en l'exécutant sur la ligne de commande.

Pour en savoir plus sur le modèle de branchement git et et leur application au développement Vérifions http://git-scm.com/book/en/Git-Branching

Answer 2

Avec flux git la branche principale tient la pointe de la dernière version, la faille dans cette déclaration est quand vous travaillez sur un logiciel qui nécessite une compilation.

Dans ce cas, la branche principale est la branche de sortie de la source à partir de laquelle vous créez la version réelle.Si vous regardez le modèle de branchement par définition, vous aurez également besoin de tous vos fichiers de support dans la branche master. De cette façon, vous pouvez toujours créer les binaires de la dernière version. Dans votre cas, vous dites que vous ne voulez pas que le client dispose d'un tas de fichiers dont il n'a pas besoin, ce qui signifie que vous aurez besoin d'un peu plus de travail après avoir publié une version. En termes de flux git, une fois que vous avez terminé la libération d'un flux git, vous devez effectuer une étape supplémentaire de compilation de votre version. Le résultat de la compilation ne devrait pas être sous contrôle de révision. Avec le logiciel original git-flow, vous devez commencer le processus de compilation à la main, si vous utilisez ma fourche, git-flow (AVH Edition), vous pouvez le faire automatiquement en utilisant des crochets.

Je suis prêt à dire que 99% des projets sur github, qui nécessitent une sorte de compilation, ont tous leurs fichiers de support dans la branche master.