Share
Git offre de nombreux avantages au développeur solo, mais il brille également beaucoup en matière de collaboration d'équipe..
La communication est la clé pour créer un bon flux de travail d'équipe avec Git. Git est polyvalent, flexible et peut s'adapter à une variété de modèles d'utilisation. Décider à l'avance des règles de conduite du flux de travail aidera à éliminer les frictions et la confusion et permettra à une équipe de tirer parti de ce que Git fait de mieux: augmenter la productivité.
Cela étant dit, ce didacticiel ne constituerait pas vraiment un didacticiel s'il ne fournissait pas un flux de travail d'équipe tangible basé sur Git que vous pouvez analyser. L'exemple suivant est basé sur un flux de travail Git très populaire créé par Vincent Driessen et appelé Git-Flow, bien qu'il diffère de certaines manières. Il existe plusieurs flux de travail Git populaires sur le Web. Je vous suggère d'en lire le plus possible afin que votre équipe puisse choisir le jeu de règles qui lui convient le mieux..
Commençons vos recherches avec le workflow suivant:
le maîtriser la branche est toujours déployable. Toujours.
Un déployable maîtriser la branche est importante pour plusieurs raisons. Premièrement, il permet à toute personne débutant dans un projet d’obtenir et de construire immédiatement sans erreurs. Rien n'est aussi frustrant que de ne pas pouvoir construire un projet inconnu.
Seconde, maîtriser indique l'état actuel de la production et / ou du produit expédié. Si des correctifs doivent être apportés, il est facile de savoir à partir de quelle branche.
Enfin, un déployable maîtriser est un filet de sécurité. Si maîtriser est toujours déployable, alors nous pouvons déployer sans souci. L'inquiétude provoque le stress et le stress provoque l'indigestion. Personne n'a besoin de ça.
le développer branche devrait être la branche principale du développement en cours. Les branches d’entités sont créées à partir de et fusionnées dans développer, et développer représente le bord saillant de notre base de code.
Depuis les deux maîtriser et développer sont des branches permanentes et très fréquentées, elles ne doivent jamais être travaillées directement. Au lieu de cela, tout le travail devrait être effectué dans les branches des fonctionnalités. Lorsque vous implémentez une nouvelle fonctionnalité, branchez à partir de développer et pirater la fonctionnalité.
Il n'y a pas de règles strictes sur le nommage des branches, en particulier pour les branches de fonctions. Si une branche est un correctif, il vaut probablement mieux y ajouter "correct". Si une branche est une version, il est généralement conseillé à la branche de suivre le format suivant: "release-X.X.X".
En général, les noms de branche devraient être descriptifs. Et peut-être drôle. Le jeu de mots occasionnel et opportun ne serait pas inacceptable.
Une fois que votre nouvelle fonctionnalité géniale est codée, il est temps de la réintégrer dans une branche partagée (supposons que nous fusionnons dans développer). Mais avant de fusionner dans développer, assurez-vous que votre branche de fonctionnalité dispose des dernières modifications apportées par développer parce qu'il peut y avoir des conflits.
Toute résolution de conflit doit avoir lieu dans votre branche de fonctionnalité. Si vous avez créé une branche pour apporter une petite modification / correction et vous n'avez pas poussé la branche vers la télécommande, rebasement développer dans votre branche de fonctionnalité, puis fusionnez votre branche de fonctionnalité dans développer. Appuyez sur, puis n'hésitez pas à supprimer votre branche de fonctionnalité locale.
Si vous avez poussé votre branche vers la télécommande, commencez par fusionner développer dans votre branche (résolution des conflits), puis fusionnez votre branche en développer. Poussez et n'hésitez pas à supprimer à la fois la branche de fonctionnalité locale et distante.
Lors du changement de base, n'oubliez pas qu'il s'agit d'un destructeur action. Ce qui signifie… soyez prudent! La redistribution est vraiment utile pour nettoyer les historiques de commit, mais vous ne voulez pas réécrire l'historique sur tout ce qui a été partagé avec quelqu'un d'autre.
Voici quelques règles pour vous protéger en cas de changement de base:
Accentsconagua
développer est une branche partagée. my-awesome-feature est une branche locale. Maintenant je suis prêt à fusionner mon-génial-fonctionnalité développer, mais je veux m'assurer que tous les changements survenus dans développer sont d'abord fusionnés dans ma branche de fonctionnalité:git checkout my-awesome-feature git rebase développer git checkout développer git merge my-awesome-feature
Disons que nous avons ramifié, nous avons codé, nous avons fusionné / rebasé à partir de développer, et maintenant nous sommes prêts à fusionner notre nouveau code dans développer. Mais devrions-nous? Peut-être que quelqu'un devrait passer en revue nos modifications d'abord…
Les revues de code sont une bonne chose! Ils vous permettent d’obtenir des informations précieuses sur le travail que vous avez effectué et, si rien d’autre, d’augmenter la probabilité que des erreurs soient détectées et corrigées..
C'est là que les requêtes d'extraction de Git (et l'interface de Bitbucket) sont utiles. (Pour un rappel sur l'ouverture et la gestion des demandes d'extraction dans Bitbucket, consultez la deuxième partie de cette série, Utilisation des demandes d'extraction en tant qu'examens de code.) Les demandes d'extraction peuvent être beaucoup plus que la simple révision du code modifié. Étant donné que les demandes d'extraction sont basées sur la marque, elles peuvent devenir des sujets de discussion et de collaboration sur des fonctionnalités individuelles. Vous pouvez incorporer des photos pour partager des conceptions, commenter directement des lignes de code et même utiliser des GIF et des émoticônes pour vous amuser..
Lorsqu'il s'agit de fusionner des demandes d'extraction, il est préférable que la fusion soit créée par la même personne qui a ouvert la demande d'extraction, car il s'agit probablement de la personne qui a écrit le nouveau code. Pour ce faire, les réviseurs doivent laisser un commentaire approuvant le nouveau code, sans pour autant appuyer sur le bouton de fusion. Une fois qu'un coéquipier donne au code un «pouce levé» (soit au sens figuré, soit littéralement avec un :pouces vers le haut: emoji), l’ouvreur de demande de tirage peut ensuite aller de l’avant et fusionner. Examen par les pairs et nettoyage des journaux - une chose merveilleuse!
Une fois que développer est prêt pour une sortie, faire une fusion dans maîtriser:
git checkout master git merge --no-ff develop
Remarquerez que --non-ff drapeau? Cela garantit que la fusion ne sera pas une avance rapide et créera un nouveau commit. Pourquoi voulons-nous cela? Nous pouvons donc le taguer! Marquez cette validation en tant que nouvelle version:
balise git -a vX.X.X -m 'Version X.X.X'
Puis fusion maîtriser retour dans développer pour que développer a la version commit.
En parlant de versions, nous devrions utiliser le versioning sémantique. Cela se résume à MAJOR.MINOR.PATCH. En général, MAJEUR est un numéro de version complet, il est utilisé pour des changements et / ou des jalons importants. Il est permis de casser la compatibilité en arrière. MINEUR est utilisé pour les nouvelles fonctionnalités. Il ne devrait pas briser toute compatibilité en amont. PIÈCE est pour les petites modifications et corrections, et ne devrait pas briser toute compatibilité ascendante. Nous devrions être dans une pré-version (0.x.x) jusqu'au lancement.
Nous ne devrions jamais expédier des erreurs.
… Mais quand nous le faisons, il est préférable de les réparer rapidement. Puisque développer peut inclure des fonctionnalités inachevées, les correctifs doivent être dérivés de la version actuelle, qui est maîtriser (parce que maîtriser est toujours déployable!).
Pour créer un correctif, branchez maîtriser, faire le correctif, puis faire un non-avance rapide fusionner en maîtriser. Marquez-le, puis fusionnez maîtriser retour dans développer (parce que nous voulons développer d'avoir le correctif aussi). N'hésitez pas à supprimer la branche de correctif.
Parlons des messages de commit Git. Adhérant à un format commun, il sera beaucoup plus facile de parcourir nos journaux. Voici quelques bonnes règles:
Si vous souhaitez en savoir plus sur la rédaction correcte du message de commit Git, consultez le message de Tim Pope..
Permettez-moi de noter une fois de plus que le flux de travail décrit ci-dessus est censé être une ligne directrice, et non des règles strictes que vous devriez strictement appliquer pour vos équipes. Si vous les aimez tous, utilisez-les! Si quelque chose ne fonctionne pas pour vous, retouchez!
Le plus important est que votre équipe s’accorde sur un flux de travail Git défini, puis s’y conforme. Une fois que cela se produira, la collaboration suivra et vous profiterez des avantages offerts par Git lorsque vous travaillez en équipe..
Découvrez des alternatives au flux de travail Git-Flow dans le guide des flux de travail Git d'Atlassian.
