Quelques principes qui pourraient t'aider à mieux préparer ton code. (En partant du principe que tu ne disposes que d'un repo local)
Déjà réserver ta branche master pour ne recueillir que des commits signifiants et stables.
Je m'explique: Cette branche ne devrait idéalement accueillir que des commits associés bijectivement à une unité changement (feature, bug, refactoring) complètement réalisée. Ceci te permettra éventuellement de reporter un changement complet de manière atomique sur une autre branche et permet de conserver un historique clair.
Comment obtenir cet historique propre alors que tu vas tester de nouvelles idées, t'y reprendre à plusieurs fois avant d'arriver au résultat attendu ?
En repartant de la branche master et en te créant une branche par changement que tu as identifié (feature branch https://www.atlassian.com/fr/git/workflows#!workflow-feature-branch ).
Tu nommes ta branche significativement "nouvel-algo-de-recherche, ...) avec un git checkout -b.
Un fois ton changement complété, il te faut l'intégrer.
Tu as as ta disposition tout un arsenal de commandes (squash, cherry-pick, amend, ...) mais le plus abouti est le rebase interactif qui te permet de réunir tous les commits, réécrire le commentaire, passer des modifications...
A la fin tu de devrais obtenir plus qu'un commit sur ton master. Tu peux ré-éditer le commentaire pour lui faire porter le nom de ton changement et le corriger si il est inconsistant avec un amend.
Une fois tout bien vérifie, il ne te reste plus qu'à supprimer ta branche de feature locale.
Pour le 2/ avec une publication
Le mieux est peut-être aussi de commencer à prendre l'habitude de travailler avec un gestionnaire de tickets (par exemple avec Github) qui te permet de mieux échanger avec la communauté et te laisse gérer l'intégration.
Le principe est le même que décrit précédemment mais cette fois-ci les tickets sont explicitement associé aux commit se qui rend l'historique de ton projet encore plus lisible.
La version stable n'accueille que des bugfix et porte les tags des release.
Ta branche de rc est la branche instable qui serait mergée régulièrement mais l'approche décrite précédemment continue d'être valable(une branche par feature et on l'intègre dans la rc dès qu'elle est prête).
Pour ne pas devoir gérer les contributeurs occasionnels (même si tu peux et faire des revues de code avant d'intégrer la branche) es forges mettent à disposition les pulls request (même si ceci existe de bas Git)
Si tu souhaites déjà rentre dans le moule avec les pull request et le gestionnaire de tickets sanns publier ton code,
il me semble que bitbucket te permet de créer des dépôts privés sinon je te conseillerais en auto-hébergement gitblit plus simple à installer que Gitlab et sans limitation. http://linuxfr.org/news/sortie-de-gitblit-1-4-x
# Tentative d'aide
Posté par El Titi . En réponse au message Gestionnaire de version : organisation et distribution. Évalué à 4. Dernière modification le 24 juin 2014 à 10:23.
Pour le 1/
Quelques principes qui pourraient t'aider à mieux préparer ton code. (En partant du principe que tu ne disposes que d'un repo local)
Déjà réserver ta branche master pour ne recueillir que des commits signifiants et stables.
Je m'explique: Cette branche ne devrait idéalement accueillir que des commits associés bijectivement à une unité changement (feature, bug, refactoring) complètement réalisée. Ceci te permettra éventuellement de reporter un changement complet de manière atomique sur une autre branche et permet de conserver un historique clair.
Comment obtenir cet historique propre alors que tu vas tester de nouvelles idées, t'y reprendre à plusieurs fois avant d'arriver au résultat attendu ?
En repartant de la branche master et en te créant une branche par changement que tu as identifié (feature branch https://www.atlassian.com/fr/git/workflows#!workflow-feature-branch ).
Tu nommes ta branche significativement "nouvel-algo-de-recherche, ...) avec un git checkout -b.
Un fois ton changement complété, il te faut l'intégrer.
Tu as as ta disposition tout un arsenal de commandes (squash, cherry-pick, amend, ...) mais le plus abouti est le rebase interactif qui te permet de réunir tous les commits, réécrire le commentaire, passer des modifications...
A la fin tu de devrais obtenir plus qu'un commit sur ton master. Tu peux ré-éditer le commentaire pour lui faire porter le nom de ton changement et le corriger si il est inconsistant avec un amend.
Une fois tout bien vérifie, il ne te reste plus qu'à supprimer ta branche de feature locale.
https://www.atlassian.com/fr/git/tutorial/rewriting-git-history#!rebase-i
Pour le 2/ avec une publication
Le mieux est peut-être aussi de commencer à prendre l'habitude de travailler avec un gestionnaire de tickets (par exemple avec Github) qui te permet de mieux échanger avec la communauté et te laisse gérer l'intégration.
Le principe est le même que décrit précédemment mais cette fois-ci les tickets sont explicitement associé aux commit se qui rend l'historique de ton projet encore plus lisible.
La version stable n'accueille que des bugfix et porte les tags des release.
Ta branche de rc est la branche instable qui serait mergée régulièrement mais l'approche décrite précédemment continue d'être valable(une branche par feature et on l'intègre dans la rc dès qu'elle est prête).
Pour ne pas devoir gérer les contributeurs occasionnels (même si tu peux et faire des revues de code avant d'intégrer la branche) es forges mettent à disposition les pulls request (même si ceci existe de bas Git)
Exemple: https://help.github.com/articles/using-pull-requests
Si tu souhaites déjà rentre dans le moule avec les pull request et le gestionnaire de tickets sanns publier ton code,
il me semble que bitbucket te permet de créer des dépôts privés sinon je te conseillerais en auto-hébergement gitblit plus simple à installer que Gitlab et sans limitation.
http://linuxfr.org/news/sortie-de-gitblit-1-4-x
Voilà, j'espère que ça t'aidera
```