J'ai besoin d'aide pour planifier le déroulement du workflow pour un environnement de développement de site spécifique récemment converti en Git (à partir de SVN).Workflow de développement Web Git: jongler avec la publication de correctifs urgents et de jalons multiples
J'ai 4 développeurs, des sites live et de transit sur le serveur client, et un serveur de dev qui héberge le "hub" (repo nu) plus 2 des repos des développeurs. Nous avons plusieurs étapes à franchir, avec un ordre d'avancement inconnu et travaillé par plusieurs développeurs. En outre, le site en direct a besoin de nombreuses solutions rapides à la volée.
Mes principales questions sont:
- Comment les corrections urgentes adressées
- Comment devrait publier une étape importante des changements vont
Mon cerveau commence à aller dans les boucles à essayer de comprendre le meilleur flux de travail Pour référence dans ce post, disons que j'ai deux jalons de changements: mobile et refonte. Voici ce que j'ai trouvé jusqu'à présent:
Chaque développeur, le repo de concentrateur et le repo de scène ont tous ces branches: mobile, refonte, master. Live repo a une branche: maître
FIXATIONS RAPIDES: développeur fait la modification de leur branche maître, pousse à hub. Puis, en direct, tire le changement du moyeu (ou de la scène d'abord s'ils ont besoin de tester auparavant). "RECADRER" MILESTONE: le développeur pousse la branche re-conception vers le hub et tire les changements sur scène. Le client teste et approuve. Au hub, le développeur fusionne la redesign en master (et crée une balise ici je pense), puis tire master en live. Ou serait-il préférable pour le développeur de fusionner les branches dans sa copie, alors il suffit de pousser son maître au hub. En outre, si un tag est créé, est-il préférable de simplement tirer le tag (si possible) sur live au lieu de tirer sur la branche master? Et les étiquettes devraient-elles seulement résider sur le repo de hub?
Bien sûr, vous ne pouvez pas toujours rebaser, en particulier avec les correctifs - vous pouvez les fusionner dans une branche de maintenance et dans la version actuelle. Vous pouvez toujours faire en sorte qu'un développeur s'assure qu'il s'agit d'une fusion rapide dans le rapport public en effectuant la fusion localement. – Cascabel
Génial, merci d'expliquer en profondeur sur les rebasages et quand le faire. A propos du hook, dites-vous que chaque fois que je crée un tag sur master, il va automatiquement pousser ce tag pour vivre? Je ne sais pas si j'ai bien compris. – spadeworkers
@spadeworkers: l'idée est d'avoir un script capable de détecter si le commit poussé est une étiquette (c'est là que 'git décrit' entre). Si c'est un commit (ie avec un tag), alors ce tag sera poussé vers un repo non nu et ce repo non nu sera extrait avec ce tag (par le même script de hook 'post-receive') – VonC