Notre équipe vient de passer de FogBugz & Kiln / Mercurial à Jira & Stash / Git. Nous utilisons le modèle Git Flow pour créer des branches, en ajoutant des branches de sous-tâches hors des branches de fonctionnalités (relatives aux sous-tâches Jira des fonctionnalités Jira). Nous utilisons Stash pour affecter un réviseur lorsque nous créons une demande d'extraction à fusionner de nouveau dans la branche parente (généralement développée mais pour les sous-tâches de nouveau dans la branche de fonctionnalité).
Le problème que nous constatons est que même avec la meilleure planification et répartition des cas de fonctionnalités, lorsque plusieurs développeurs travaillent ensemble sur la même fonctionnalité, par exemple sur le front-end et le back-end, s'ils travaillent sur du code interdépendant qui est dans des branches distinctes, un développeur finit par bloquer l'autre.
Nous avons essayé de tirer entre les branches les uns des autres au fur et à mesure de notre développement. Nous avons également essayé de créer des branches d'intégration locales que chaque développeur peut extraire de plusieurs branches pour tester l'intégration au fur et à mesure de leur développement. Enfin, et cela semble fonctionner le mieux pour nous jusqu'à présent, bien qu'avec un peu plus de frais généraux, nous avons essayé de créer une branche d'intégration à partir de la branche de fonctionnalité dès le départ. Lorsqu'une branche de sous-tâche (hors de la branche de fonctionnalité) est prête pour une demande d'extraction et une révision de code, nous fusionnons également manuellement ces ensembles de modifications dans cette branche d'intégration de fonctionnalité. Tous les développeurs intéressés peuvent alors passer de cette branche d'intégration à d'autres branches de sous-tâches dépendantes. Cela empêche quiconque d'attendre une branche dont il dépend pour passer l'examen du code.
Je sais que ce n'est pas nécessairement un problème Git - cela a à voir avec le travail sur du code interdépendant dans plusieurs branches, mélangé avec notre propre processus de travail et notre culture. Si nous n'avions pas la politique stricte de révision de code pour le développement (véritable branche d'intégration), le développeur 1 pourrait fusionner pour se développer pour le développeur 2. Une autre complication est que nous sommes également tenus de faire des tests préliminaires dans le cadre du processus de révision du code avant de remettre la fonctionnalité à QA, ce qui signifie que même si le développeur frontal 1 tire directement de la branche du développeur principal 2 car ils si le développeur principal 2 se termine et que sa demande d'extraction est en attente de révision de code pendant une semaine, le développeur frontal 2 ne peut techniquement pas créer sa demande d'extraction / révision de code car son réviseur de code ne peut pas tester car développeur back-end 2 '
En fin de compte, nous nous trouvons dans une approche beaucoup plus sérielle plutôt que parallèle dans ces cas, en fonction de la route que nous empruntons, et nous aimerions trouver un processus à utiliser pour éviter cela.
La dernière chose que je mentionnerai est que nous réalisons en partageant le code entre les branches qui n'ont pas été revues et finalisées, mais nous utilisons essentiellement le code bêta des autres. Dans une certaine mesure, je ne pense pas que nous puissions éviter cela et sommes prêts à l'accepter dans une certaine mesure.