Notre entreprise utilise actuellement un modèle de branchement simple tronc / version / correctifs et aimerait savoir quels modèles de branchement fonctionnent le mieux pour votre entreprise ou votre processus de développement.
Workflows / modèles de branchement
Voici les trois principales descriptions de ce que j'ai vu, mais elles se contredisent partiellement ou ne vont pas assez loin pour trier les problèmes ultérieurs que nous avons rencontrés (comme décrit ci-dessous). Ainsi, jusqu'à présent, notre équipe ne propose pas de solutions aussi géniales. Faites-vous quelque chose de mieux?
Fusion vs rebasage (enchevêtrement vs historique séquentiel)
Devrait-on
pull --rebase
ou attendre la fusion avec la ligne principale jusqu'à ce que votre tâche soit terminée? Personnellement, je penche pour la fusion car cela préserve une illustration visuelle de la base sur laquelle une tâche a été lancée et terminée, et je préfère mêmemerge --no-ff
à cet effet. Il présente cependant d'autres inconvénients. De plus, beaucoup n'ont pas réalisé la propriété utile de la fusion - qu'elle n'est pas commutative (fusionner une branche de sujet en maître ne signifie pas fusionner maître dans la branche de sujet).Je recherche un workflow naturel
Parfois, des erreurs se produisent parce que nos procédures ne capturent pas une situation spécifique avec des règles simples. Par exemple, un correctif nécessaire pour les versions antérieures devrait bien sûr être basé suffisamment en aval pour pouvoir fusionner en amont dans toutes les branches nécessaires (l'utilisation de ces termes est-elle suffisamment claire?). Cependant, il arrive qu'un correctif arrive dans le maître avant que le développeur ne se rende compte qu'il aurait dû être placé plus en aval, et si cela est déjà poussé (pire encore, fusionné ou quelque chose basé sur lui), l'option restante est la sélection des cerises, avec ses périls associés. Quelles règles simples comme celles-ci utilisez-vous?On y trouve également la maladresse d'une branche de sujet excluant nécessairement les autres branches de sujet (en supposant qu'elles sont ramifiées à partir d'une ligne de base commune). Les développeurs ne veulent pas terminer une fonctionnalité pour en démarrer une autre en ayant l'impression que le code qu'ils viennent d'écrire n'est plus là
Comment éviter de créer des conflits de fusion (à cause de la sélection)?
Ce qui semble être un moyen sûr de créer un conflit de fusion est de choisir entre les branches, elles ne pourront plus jamais être fusionnées? Est-ce que l'application du même commit dans revert (comment faire?) Dans l'une ou l'autre branche pourrait résoudre cette situation? C'est une des raisons pour lesquelles je n'ose pas pousser pour un workflow largement basé sur la fusion.
Comment se décomposer en branches topiques?
Nous nous rendons compte qu'il serait génial d'assembler une intégration terminée à partir de branches de sujet, mais souvent le travail de nos développeurs n'est pas clairement défini (parfois aussi simple que de "fouiner") et si du code est déjà entré dans un sujet "divers", il ne peut plus être retiré de là, selon la question ci-dessus? Comment travaillez-vous pour définir / approuver / graduer / publier vos branches thématiques?
Des procédures appropriées telles que la révision du code et l'obtention du diplôme seraient bien sûr très intéressantes.
Mais nous ne pouvons tout simplement pas garder les choses suffisamment intriquées pour gérer cela - des suggestions? branches d'intégration, illustrations?
Voici une liste de questions connexes:
- Quelles sont les bonnes stratégies pour permettre aux applications déployées d'être hotfixables?
- Description du flux de travail pour l'utilisation de Git pour le développement en interne
- Flux de travail Git pour le développement du noyau Linux d'entreprise
- Comment gérez-vous le code de développement et le code de production? (merci pour ce PDF!)
- git releases management
- Git Cherry-pick vs Merge Workflow
- Comment sélectionner plusieurs commits
- Comment fusionner des fichiers sélectifs avec git-merge?
- Comment choisir une gamme de validations et fusionner dans une autre branche
- Flux de travail ReinH Git
- flux de travail git pour effectuer des modifications que vous ne repousserez jamais à l'origine
- Choisissez une fusion
- Flux de travail Git approprié pour le système d'exploitation et le code privé combinés?
- Gérer le projet avec Git
- Pourquoi ne pouvez-vous pas modifier le fichier de fusion Git avec un parent / maître modifié.
- Bonnes pratiques de branchement / rebasage de Git
- Quand est-ce que "git pull --rebase" me causera des ennuis?
- Comment le DVCS est-il utilisé dans les grandes équipes?
Découvrez également ce que Plastic SCM écrit sur le développement axé sur les tâches , et si Plastic n'est pas votre choix, étudiez le modèle de branchement de nvie et ses scripts de support .