2016-07-07 2 views
7

Par exemple, il existe plusieurs grandes fonctions: User [besoin de développer UserControl, UserModel, UserService], et Admin, Post, Comment.Que faites-vous lorsque vous trouvez un bug dans une autre fonction lors du développement d'une fonction?

Vous êtes maintenant dans la branche features/post, développant des fonctions liées aux postes. Mais vous rencontrez quelques bugs dans les fonctions connexes User. Donc, en termes de gitflow, quelle est la manière suggérée de faire?

  1. ajouter TODO ou Fix me aux fonctions relatives à l'utilisateur, et corriger le bug après la fin du développement de la poste et a fusionné le code à maîtriser?

  2. Stash poste inachevé code lié, créez une branche fix, corriger le bug, fusionner pour features/post, stash pop le poste inachevé code lié, puis continuer?

Répondre

3

Vous pouvez fixer librement ce que vous voulez, qu'il soit ou non lié au "sujet" sur lequel vous travaillez.

Ensuite, utilisez git commit --patch pour ajouter uniquement valider les modifications qui respectent le sujet. (Il vaut la peine d'apprendre tous les détails de ce flux de travail, y compris comment diviser les mecs en plus petits changements, et comment éditer les mecs qui ne peuvent pas être divisés, mais qui contiennent un mélange de changements désirés et non désirés). Lorsque les validations de rubrique sont toutes effectuées à l'aide d'une ou plusieurs opérations git commit --patch, tout ce qui reste dans la copie de travail sont les modifications hors sujet. À ce stade, vous pouvez git checkout à une branche différente pour les valider, le cas échéant, en utilisant git stash save et git stash pop pour contourner toute plainte indiquant que vous avez des changements non planifiés.

Si tout est dans la même branche, alors peut-être que l'ordre n'a pas d'importance. Vous pouvez juste git commit --patch le correctif que vous avez découvert, puis continuez avec le sujet. Si le correctif se situe au milieu des correctifs de rubrique en cours, vous pouvez toujours le git rebase -i: le redéfinir interactivement de sorte que les validations de sujet soient ensemble et que le correctif incident soit avant ou après. Dans mon organisation logicielle, je devais créer un ticket et obtenir un numéro de bogue pour ce bugfix incident, et le soumettre à Gerrit pour examen. Si quelque chose d'évident semble être approuvé rapidement et facilement, je le ferais d'abord, avant les changements «importants» sur lesquels je travaille.

0

Je ne suis pas flux git spécifiquement, mais voici ce que j'essaie de faire:

  • Stash, ou utilisez git-worktree.
  • Correction du bug dans la branche amont concernée.
  • Fusionner le correctif dans la branche de travail (habituellement je le rebase plus tard).

Sinon, vous pouvez d'abord le fixer dans la branche courante comme une validation discrète, puis git cherry-pick dans la branche amont et git rebase laisser tomber de la branche actuelle.

1

Je n'ai pas trouvé que GitFlow le définit. Pour moi, en me basant sur le critique du BUG, ​​je déciderai de le réparer immédiatement ou d'ajouter TODO pour le réparer plus tard.

Je ne le répare pas dans la même branche avec la fonction de développement en cours, car cela rendra mes coéquipiers confus lorsqu'ils examineront mon code source.

0

Ceci est un peu une question basée sur l'opinion - git-flow ne vous oblige pas à résoudre ce problème d'une manière particulière.

Je vais généralement revenir à la branche develop, créer une nouvelle branche de fonctionnalité, y corriger le bug, puis une fois celle-ci fusionnée, je vais rebasculer la fonctionnalité sur laquelle je travaillais à l'origine pour développer le correctif de bogue.

Si le bogue est urgent et que le développement n'est pas le même que le master, j'utiliserai une branche de correctif, et rebasculerai à nouveau ma branche sur développer une fois le correctif fusionné en master et développé.