- je ne dis pas qu'un outil distribué va à l'encontre du partage, je ne dis pas que c'est malsain, je dis que ça peut induire des comportements malsain. [...] Tu vois ce que je veux dire ? Et c'est cette possibilité qui me chagrine et que je trouve assez absente des VCS. Mais après, je peux me tromper et avoir une mauvaise vision.
Je ne me permettrais pas de dire que tu te trompes, ce serait pédant et subjectif. Mais je n'arrive vraiment pas à comprendre pourquoi tu considères que les DVCS permettent plus facilement de copier du code et de le conserver en local que ne le ferait SVN ou même un tarball.
En quoi le fait que ça passe par git, svn, wget, scp rsync ou autre chose change la donne ?
Mais après, je peux me tromper et avoir une mauvaise vision. Disons que nos visions divergent. Après dire qu'une vision est bonne ou mauvaise, le bien le mal, le manichéisme toussa, ça ne me semble pas pertinent dans un échange prolifique entre deux personnes sensées.
le workflow de Linux est certes exemplaire, mais ce n'est qu'un exemple de workflow parmi tout ceux proposés par git
C'est justement toute la beauté de git. Avec git, tu peux faire un workflow svn. Mais il en existe beaucoup d'autres.
C'est aussi pour ça que j'aime git.
Puisque je te tiens, je vais te poser une question purement pratique : quand créer une branche ?
Bonne question :)
Je me la suis également longtemps posée. Et comme je manque de créativité et que j'ai eu la chance de tomber sur un article[1] fort sympathique sur identica (via le groupe !git), je m'en suis inspiré.
Le problème, c'est que c'est plutôt orienté pour les gros projets. Moi je ne suis qu'un petit développeur du dimanche (mais enthousiaste).
Mais ce n'est pas tant un problème que ça. Il suffit de picorer dedans et de prendre ce qui est nécessaire ou pas. Du moins c'est comme ça que je procède.
Selon le projet, je ne fais pas toujours de branches (autres que la principale bien sûr), parfois j'y ajoute juste une branche de développement. Parfois une branche pour une feature, si je sais que ça va mettre un certain nombre de temps à développer et que je ferais d'autre release entre temps.
Bref, je pense que ce document peut servir de référence, qu'il est tout à fait adapté pour les gros projets, et adaptable pour les plus petits projets.
C'est aussi ce qui peux expliquer que tu ait pu voir plusieurs méthodes différentes. Chacun a une expérience différente en fonction des projets différents. Mais je pense aussi (et je peux me tromper), que plus le projet grossit, plus le modèle de développement tend vers quelque chose de similaire, l'exemple le plus abouti étant Linux.
[^] # Re: Git malgré moi
Posté par j_kerviel . En réponse au journal Git malgré moi. Évalué à 8.
- je ne dis pas qu'un outil distribué va à l'encontre du partage, je ne dis pas que c'est malsain, je dis que ça peut induire des comportements malsain. [...] Tu vois ce que je veux dire ? Et c'est cette possibilité qui me chagrine et que je trouve assez absente des VCS. Mais après, je peux me tromper et avoir une mauvaise vision.Je ne me permettrais pas de dire que tu te trompes, ce serait pédant et subjectif. Mais je n'arrive vraiment pas à comprendre pourquoi tu considères que les DVCS permettent plus facilement de copier du code et de le conserver en local que ne le ferait SVN ou même un tarball.
En quoi le fait que ça passe par git, svn, wget, scp rsync ou autre chose change la donne ?
Mais après, je peux me tromper et avoir une mauvaise vision.Disons que nos visions divergent. Après dire qu'une vision est bonne ou mauvaise, le bien le mal, le manichéisme toussa, ça ne me semble pas pertinent dans un échange prolifique entre deux personnes sensées.le workflow de Linux est certes exemplaire, mais ce n'est qu'un exemple de workflow parmi tout ceux proposés par gitC'est justement toute la beauté de git. Avec git, tu peux faire un workflow svn. Mais il en existe beaucoup d'autres.
C'est aussi pour ça que j'aime git.
Puisque je te tiens, je vais te poser une question purement pratique : quand créer une branche ?Bonne question :)
Je me la suis également longtemps posée. Et comme je manque de créativité et que j'ai eu la chance de tomber sur un article[1] fort sympathique sur identica (via le groupe !git), je m'en suis inspiré.
Le problème, c'est que c'est plutôt orienté pour les gros projets. Moi je ne suis qu'un petit développeur du dimanche (mais enthousiaste).
Mais ce n'est pas tant un problème que ça. Il suffit de picorer dedans et de prendre ce qui est nécessaire ou pas. Du moins c'est comme ça que je procède.
Selon le projet, je ne fais pas toujours de branches (autres que la principale bien sûr), parfois j'y ajoute juste une branche de développement. Parfois une branche pour une feature, si je sais que ça va mettre un certain nombre de temps à développer et que je ferais d'autre release entre temps.
Bref, je pense que ce document peut servir de référence, qu'il est tout à fait adapté pour les gros projets, et adaptable pour les plus petits projets.
C'est aussi ce qui peux expliquer que tu ait pu voir plusieurs méthodes différentes. Chacun a une expérience différente en fonction des projets différents. Mais je pense aussi (et je peux me tromper), que plus le projet grossit, plus le modèle de développement tend vers quelque chose de similaire, l'exemple le plus abouti étant Linux.
En espérant que ça d'aide au moins un peu.
[1] http://nvie.com/posts/a-successful-git-branching-model/
(Bon j'ai encore pondu un roman. Désolé pour le paté, j'espère que je n'ai pas noyé les potentielles informations importantes dans le bruit).