Hello,
Hello,
Merci pour ta réponse.
Je suis tout à fait d’accord avec l’analyse et le retour d’expérience de cette personne.
Ce n’est pas parce qu’on utilise un outil « git » que nous connaissons Git. Personnellement, c’est exactement pour ça que j’utilise lesdits outils! Git n’étant pas ma tasse de thé. Je vois ses avantages mais des choses me manquent de SVN. Bref. Pas de débat, c’est juste une affinité. 
J’avoue qu’aujourd’hui je ne vois pas ce qu’on faisait avec svn qui ne soit pas possible avec git.
En complément de la réponse de RealET, le fait de faire un svn checkout, ça ne ramène pas des Go de données (selon l’ancienneté et le type de données historisées). Et si dans le dépôt SVN, je ne désire qu’un répertoire, ben, je peux prendre ce répertoire uniquement sans problème. Sur git, je dois prendre l’entièreté du projet pour pouvoir récupérer ledit répertoire.
Pour le « Go de données », j’ai eu des collègues juniors qui, sans le faire exprès, versionnaient le contenu des répertoires « IMG », « local » et « tmp »… Quand je m’en rendais compte en faisant git clone xxxxxx, c’était un peu « trop tard » ou demandait bcp de manipulation.
L’existence de
la branche « stable » (nécessaire à twgit) casserait ce processus ?
A priori non, ça ne casse pas le processus de tag => zip.
C’est ce qu’il me semblait mais je préférais demander l’avis et l’autorisation de la communauté.
Oui mais ça ne doit pas devenir systématique non plus aujourd’hui.
On ne doit pas imposer un commit une montée de version.
Justement, l’utilisation de twgit n’interdit aucunement l’utilisation des commandes git habituelles! le twgit facilite la création de branche, de tags, de merge, etc. Le dépôt git reste ainsi très propre, pas de branches inutiles/inutilisées.
Donc, la montée de version peut comprendre plusieurs commits sans soucis.
De plus, twgit permettra de signifier à l’ensemble des personnes travaillant sur le dépôt qu’il y a une hotfix en cours, ou une release. Bien entendu, l’alerte est faite si on utilise les commandes twgit. Donc, encore une fois, une meilleure gestion du projet git.
Cela étant dit, pourquoi diable n’ont-ielles pas conservé « master ». Elle devient quoi cette branche « master » dans tout ça ?
« Master » devient une branche morte en quelques sortes. Mais, ici, dans la communauté, on utilise la branche master. Je verrai (soit par un hook, soit manuellement) a faire un merge de la stable dans le master régulièrement.
Oui alors moi ça me pose un problème ça.
Je ne suis pas chaud à ce que pour certains plugins on ait une branche master qui ne soit plus le master ou qui doublonne avec une autre branche de temps en temps.
A mon avis un outil perso ne doit pas imposer un formalisme.
Je n’ai pas trouvé comment changer cette dépense à « stable ». Mais comme a pu dire RastaPopoulos, un mouvement s’interroge sur le bien fondé du terme « master ».
(même si pour le coup, probablement sans le faire exprès, ielles éliminent le problème de terminologie master/slave…).
En effet, je n’ai jamais aimé cette terminologie de « master » qui sous-entend « slave » habituellement dans ce contexte.
Si nous avions plutôt utilisé le terme de « master » en tant que « maître », « expert », ou tout autre synonyme, cela aurait été moins subversif.
En anglais ça veut dire « principal ».
Il n’y a donc aucune autre connotation.
Cela dépend du contexte et de la sensibilité des uns et des autres. 
Personnellement, de mon Histoire, quand je lis « master », je pense inconsciemment à « slave ».
Ybbet
