Le nouveau développeur ne peut pas suivre les fusions de succursales
Je suis le nouveau développeur - c'est ma première position de programmation.
Mon problème est le suivant: nous utilisons git - J'ai coupé une branche de notre branche develop, puis je commence à travailler sur la tâche secondaire qui m'a été assignée. C'est très lent, car je suis inexpérimenté. Au moment où je suis prêt à fusionner ma branche dans develop les autres ont apporté tellement de changements que la résolution des conflits est écrasante (il semble en fait plus facile de supprimer mon travail et de recommencer la tâche, laquelle des n'est pas une solution durable).
Comment surmonter cela? Existe-t-il une tactique que je peux utiliser autre que "mieux coder"? J'ai l'intention d'en parler avec mon superviseur la semaine prochaine.
Vous obtenez des conflits de fusion si les modifications que vous avez apportées à votre branche sont proches de celles effectuées par vos collègues dans la branche develop entre-temps, c'est-à-dire si vous et vos collègues avez modifié les mêmes lignes de code ou des lignes adjacentes dans le même fichier.
Ainsi, pour réduire la probabilité de conflits de fusion, vous pouvez essayer de fusionner plus tôt afin que vos collègues aient modifié moins de lignes entre-temps, ou vous pouvez essayer de changer moins de lignes vous-même.
Pour modifier moins de lignes vous-même, assurez-vous de n'effectuer que des modifications liées à votre tâche.
Si vous avez besoin d'expérimenter différentes façons d'atteindre votre objectif, peut-être que certaines de vos expériences ont changé de ligne qui n'ont pas vraiment besoin d'être changées? Annulez ces modifications avant de fusionner.
Il existe également des commandes Git qui peuvent vous aider à modifier le moins de lignes possible:
git diffetgit diff --stagedpour voir quelles lignes vous avez modifiées.git add -ppour n'ajouter que certaines de vos modifications dans un fichier.git commit --amendetgit rebase -ià Tweak vous valide déjà dans votre branche de fonctionnalité locale avant de les pousser vers d'autres référentiels Git.
(Le fait de modifier le moins de lignes possible peut également faciliter la révision de votre travail ou l'utilisation d'outils qui fonctionnent sur les différences entre les validations, tels que git cherry-pick, git rebase, git bisect, et git blame.)
Mais même si vous réduisez la probabilité de conflits de fusion, vous rencontrerez parfois des conflits de fusion. N'ayez donc pas peur d'eux, mais apprenez à résoudre les conflits.
Je suppose que vous utilisez git. Si oui, utilisez git rebase -i (le -i signifie interactif). Faites-en une tâche quotidienne (encore plus fréquemment, si nécessaire) pour rebaser votre branche contre la branche de développement. Cela apporte les modifications progressivement tous les jours (au moins) pour maintenir votre branche de fonctionnalités à jour. S'il y a des conflits lors de votre rebase quotidien, vous devez discuter avec votre équipe de qui travaille sur quoi.
Si vous l'exécutez quotidiennement, vous n'aurez probablement pas besoin de la partie interactive. Laissez-le faire ce qu'il veut.
Je suis un développeur assez expérimenté, et il me faut encore pas mal de temps pour me mettre au courant d'un nouveau projet. Dans votre cas, il semble que vous ayez plusieurs personnes travaillant simultanément sur le même projet, il s'agit donc d'un très grand projet ou d'un nouveau projet qui évolue rapidement. Dans les deux cas, ne vous inquiétez pas si cela vous prend plusieurs mois pour entrer dans le courant. Si je change de projet pendant 2 ou 3 semaines, puis que je reviens en arrière, cela peut me prendre quelques heures (voire un jour ou deux) pour me réintégrer complètement dans un projet que j'ai écrit à 100% par moi-même!
En bref, ne vous inquiétez pas d'être lent en ce moment. La façon de s'améliorer est de continuer à pratiquer. N'ayez pas peur de demander à d'autres développeurs des aspects des projets que vous ne comprenez pas.
ÉDITER:
Ou utilisez merge. C'est aussi une option. Ainsi, ce qui précède serait: "utiliser git rebase -i (le -i signifie interactif) ou git merge ". Quant à savoir lequel utiliser, discutez-en avec le reste de votre équipe. Ils peuvent (ou non) avoir de fortes préférences dans les deux cas. Il est clair que certaines personnes le font ont de fortes préférences.
Cela pourrait être le signe d'une mauvaise ingénierie logicielle de la part de l'entreprise. Trop d'interdépendances, différents problèmes avec des fonctionnalités qui se chevauchent, tenter de résoudre les problèmes dans le mauvais ordre, etc. peuvent provoquer la situation que vous décrivez. Je suggère de fusionner régulièrement develop dans votre branche pendant le développement
Je pense que les réponses acceptées sont plus d'ordre technique "comment utiliser mieux Git", je pense que c'est plus un problème d'équipe qu'un problème d'ingénierie ou d'outillage.
Si vous rencontrez de nombreux conflits de fusion, cela signifie que vous et un autre membre de l'équipe marchez les uns sur les autres.
.
Dans mon équipe, nous tendons vers un haut degré d'appropriation des tâches.
Je prendrai généralement la propriété pleine et entière de deux ou trois fichiers à la fois et j'y travaillerai dans une succursale pendant un jour ou deux au maximum.
Généralement, si quelqu'un d'autre touche ces fichiers, ce n'est que si cela est absolument nécessaire pour leurs propres tâches, nous ne travaillons généralement pas ensemble sur le même bloc de tâches!
Si vous constatez que vous devez fusionner beaucoup, alors tout le code de vos équipes est au même endroit (ce qui est quelque chose à éviter en soi) ou toutes vos tâches le sont.
Cela dit, en tant que nouveau développeur, vous n'êtes probablement pas en mesure d'appliquer, de demander ou même de suggérer vraiment une quelconque restructuration.
Ce à quoi je m'attendrais, c'est que vos tâches aient été assignées comme des trucs d'apprentissage qui devraient être raisonnablement accessibles à votre niveau de compétence afin de vous faciliter dans l'équipe. Ils ont probablement été éliminés des tâches d'un collègue qui travaille toujours dans le même domaine, d'où vos conflits de fusion.
. votre manager à s'inquiéter de vos progrès.
Vous deviendrez plus rapide et plus confiant au fur et à mesure, et vos collègues vous donneront plus d'autonomie et vous gêneront moins en conséquence.
La chose la plus importante à propos de la fusion est que plus vous attendez, plus cela devient douloureux. Et le problème devient plus que linéaire. Trois fois plus de conflits représentent neuf fois plus de travail. Il existe quelques stratégies:
Fusionnez avec la branche de développement chaque fois qu'elle change, de sorte que vous êtes toujours proche d'elle et que vous n'avez jamais un grand nombre de conflits.
Si vous prenez beaucoup de temps, cela peut être dû au fait que vous passez la plupart du temps à déterminer quelles sont les modifications, puis à mettre un peu de temps à les mettre en œuvre. Si tel est le cas, fusionnez avec la branche de développement avant de commencer les modifications de code réelles.
Discutez avec vos collègues des stratégies pour éviter les conflits. Vous obtenez des conflits si deux personnes modifient le même code. Pas seulement le même fichier, mais le même code. J'ai donc besoin d'une nouvelle fonction functionA et vous avez besoin d'une nouvelle fonction functionB, et nous l'ajoutons tous les deux à la fin du même fichier, nous avons un conflit. Si nous l'ajoutons à différents endroits, pas de conflit. Si nous l'ajoutons tous les deux à un endroit du fichier auquel il appartient logiquement, il y a de fortes chances que nous n'ayons aucun conflit.
Si vous avez des conflits, procurez-vous un bon outil de différenciation, afin de pouvoir comparer la branche de développement avant votre fusion, votre code avant la fusion, votre code d'origine et le code fusionné, et fusionner à la main.
Pire cas: vous ne jetez pas votre travail, mais utilisez un bon outil de différenciation pour savoir exactement quelles modifications vous avez apportées, branchez-vous à nouveau à partir de develop et appliquez toutes les modifications que vous avez apportées manuellement au lieu de les retaper.
Au moment où je suis prêt à fusionner ma branche de nouveau dans le développement (accent sur le mien)
Gestion des conflits dans git merge est souvent plus simple qu'en git rebase. Dans Git Merge, vous pouvez voir la liste complète des fichiers qui ont été modifiés en même temps. Peu importe le nombre de validations effectuées par d'autres collègues, vous devrez fusionner ne fois. Avec le workflow de rebase, vous pouvez finir par obtenir les mêmes conflits encore et encore et devoir les revoir manuellement. Vous pouvez finir par corriger le 13ème commit et vous sentir comme vous ne pouvez pas voir la lumière du tunnel .
D'après mon expérience, lorsque j'ai tenté de résoudre naïvement des conflits de rebase répétés, j'ai fini par perdre les modifications de quelqu'un ou avec une application qui ne compilait même pas. Souvent, mes collègues et moi-même avons fait beaucoup de travail, mais nous sommes devenus tellement submergés par la complexité de la répétition des conflits que nous avons dû abandonner et perdre notre travail précédent après une poignée de rebases.
Je vais vous suggérer quelques techniques, mais elles ne peuvent que faciliter la fusion plutôt que d'automatiser la tâche.
- Fichiers de ressources/langues. Si vous avez des modifications additives dans un fichier de ressources, assurez-vous de toujours les déplacer à la fin du fichier afin de pouvoir facilement rappeler votre change contre autres 'change. Vous pouvez peut-être copier et coller vos modifications en bas, ou simplement supprimer les marqueurs de conflit
- Ne. Pas. ABSOLUMENT. RE-format. Ni vous ni vos collègues développeurs ne devez effectuer un "reformatage de code massif" pendant le travail quotidien. Le reformatage du code ajoute un nombre excessif de faux positifs dans la gestion des conflits. Le reformatage du code peut être effectué
- De manière incrémentale, par ex. par chaque développeur sur chaque commit, dès qu'ils utilisent un outil automatisé (par exemple, Eclipse a une option pour reformater lors de l'enregistrement, Vanilla Visual Studio n'en a pas). Absolument chaque développeur doit utiliser les mêmes normes de formatage de code, codées dans un fichier de format consommé par votre IDE. Pour vous donner une idée, que ce soit 4 espaces ou 2 tabulations, cela n'a pas d'importance, mais c'est vraiment important si tout le monde utilise la même chose.
- Juste avant la sortie, par un chef d'équipe. Si un commit de "reformatage de code" se produit lorsque les gens ne travaillent pas sur des branches, c'est-à-dire avant de se connecter, les choses seront plus faciles
- Review la répartition du travail entre collègues. Celui-ci est la partie où la plupart des ingénieurs viennent. Comme indiqué par d'autres réponses, c'est une odeur de conception si plusieurs développeurs effectuant des tâches différentes doivent toucher les mêmes ressources. Vous devrez peut-être discuter avec votre chef d'équipe de la partie à modifier par chaque développeur simultané.
J'ai également vu de mauvaises habitudes dans les workflows Git dans mes équipes. Souvent, les gens s'engagent trop dans leurs succursales. J'ai personnellement vu un développeur ajouter 10 à 20 commits étiquetés "fix", chacun validant une ou deux lignes. Notre politique est que les commits soient étiquetés avec des billets JIRA pour vous donner une idée.
@JacobRobbins suggère de faire git rebase une tâche quotidienne. Je voudrais pousser son approche vers l'avant.
Tout d'abord, utilisez rebase une fois juste pour réduire le nombre de validations à une poignée. Et rebasez uniquement sur la branche original develop, qui est la validation à partir de laquelle vous avez créé une branche. Quand je dis poignée, je pourrais dire 3 ou 4 (par exemple, tous les frontaux, tous les backends, tous les correctifs de base de données) ou tout chiffre humainement raisonnable. Après les avoir consolidés, utilisez fetch et travaillez votre rebase sur la branche amont. Cela ne vous évitera pas de conflit à moins que votre équipe ne revoie sa propre approche, mais vous rendra la vie moins douloureuse.
Si vous avez des questions supplémentaires sur les tâches spécifiques, n'hésitez pas à rechercher et à poser sur Stackoverflow.
[Modifier] sur la règle du non-reformatage et du scoutisme. J'ai légèrement reformulé RE-format pour souligner que ce que je veux dire est la tâche de formater à partir de zéro le fichier source entier, y compris le code qui n'a pas été touché par vous. Au contraire de toujours formater votre propre code, ce qui est parfaitement boy-scouty, un certain nombre de développeurs, dont moi-même, sont utilisés pour reformater le fichier entier avec les capacités de l'IDE. Lorsque le fichier est touché par d'autres, même si les lignes affectées ne sont pas modifiées dans leur contenu et leur sémantique, Git le verra comme un conflit. Seul un éditeur très puissant prenant en charge la langue peut suggérer que le conflit n'est lié qu'à la mise en forme et à la fusion automatique du fragment le mieux formaté. Mais je n'ai aucune preuve d'un tel outil.
Après tout, la règle du scoutisme ne vous oblige pas à nettoyer le gâchis des autres. Seulement le vôtre.
Tout d'abord, ne pensez pas à rejeter vos modifications. Vous perdrez des opportunités d'apprendre le processus de fusion.
Deuxièmement, trouvez une personne qui a travaillé sur les fichiers à l'origine du conflit. Vous pouvez voir l'histoire. Parlez à la personne et résolvez les conflits dans ces fichiers. Faites de même pour les autres conflits.
S'il y a trop de conflits, votre tâche peut être mineure, mais répétitive. Essayez de trouver un motif. Cela aiderait à résoudre les conflits par les outils client Git UI. J'utilise TortoiseGit. Il aide à fusionner.
Et pour éviter à l'avenir,
C'est une très bonne pratique de fusionner régulièrement la branche de développement avec votre branche de fonctionnalité.
Si le CI est activé, voyez si l'outil CI fournit une construction de branche. Cela devrait s'appuyer sur chaque archivage que vous effectuez dans votre branche de fonctionnalité, mais après la fusion, développez la branche.
Il y a ici quelques problèmes sous-jacents. Vos problèmes de fusion ne sont probablement pas de votre faute et sont le plus souvent le symptôme de mauvaises pratiques.
1) Idéalement, vous fusionneriez votre branche pour la développer tous les jours. Essayez d'avoir du code de travail au moins une fois par jour qui passe tous les tests afin que vous puissiez fusionner en développement.
2) Si vous n'avez pas de code de travail à un moment quelconque de votre journée de travail habituelle, vous avez probablement trop de gros morceaux de code pour travailler. Vous devez diviser votre tâche en tâches plus petites qui peuvent être terminées (idéalement indépendamment les unes des autres) plus rapidement afin de pouvoir fusionner.
3) Les fichiers de vos projets sont probablement trop volumineux. S'il existe de nombreux conflits de fusion pour un fichier, trop de personnes travaillent sur un seul fichier. Idéalement, quelque chose sur lequel une personne travaille devrait être distinct de ce sur quoi tout le monde travaille.
4) Votre équipe est peut-être trop grande. Si vous trouvez plus facile de jeter une fonctionnalité entière et de recommencer, il est probable qu'il y ait trop de gens qui commettent du code dans le même référentiel.
5) Vous ne disposez peut-être pas de normes de formatage de code cohérentes. Si vous n'utilisez pas tous systématiquement le même formatage de code, vous obtiendrez de nombreux conflits différents pour le même code. Selon la configuration de votre git, cela peut même se résumer à des conflits d'espaces (fins de ligne, indentation, tabulations vs espaces).
6) Les gens pourraient pousser leurs changements directement vers la branche develop.
Voici ce que vous pouvez faire: 1) Si vous ne pouvez pas fusionner en développement tous les jours, fusionner/rebaser se développer dans votre branche tous les jours (ou plus souvent).
2) Essayez de séparer votre code du code de chacun.
3) Discutez avec le reste de l'équipe de fonctionnalités plus petites, de normes de codage cohérentes et d'une meilleure organisation du code (fichiers plus petits, fonctions plus petites).
Il semble en fait plus facile d'abandonner mon travail et de recommencer la tâche, ce qui bien sûr n'est pas une solution durable)
La plupart du temps, c'est ce que je fais, la première fois que je corrige un bogue ou que je modifie le système, j'apprends à le faire. La prochaine fois que je corrige le même bug, cela ne prend que 1% du temps car je comprends maintenant le problème.
Je trouve aussi que quand je refais un peu de travail, j'écris du meilleur code .....
Par conséquent, il n'y a rien de mal à créer une nouvelle branche à partir du maître, à y refaire votre travail, tout en utilisant votre "branche privée" pour vous rappeler ce que vous devez faire.
Il est également possible que vous ayez découvert un moyen de diviser votre modification en parties logiques et correctes, chacune pouvant être fusionnée dans la branche principale une fois terminée. Par exemple, les tests unitaires et les modifications apportées au code principal peuvent être effectués et fusionnés. Ensuite, dans une opération distincte, vous pouvez effectuer les modifications d'interface utilisateur qui les utilisent, ce qui réduit le risque que quelqu'un d'autre modifie le même fichier d'interface utilisateur.
Si vous ne souhaitez pas fusionner la branche de développement dans votre branche trop souvent, vous pouvez obtenir un flux de travail qui ressemble plus à svn en utilisant git pull --rebase. Cela va tirer les nouveaux commits et rebaser vos commits sur eux. Cela signifie que lorsque vous fusionnez votre branche en développement, ce sera une fusion à avance rapide (comme si vous aviez ajouté toutes vos validations passées en même temps l'une après l'autre) et sans aucun conflit de fusion, car vous les avez toutes résolues pendant git pull --rebase.
Mais plus vous vous engagez avant de fusionner votre branche en développement ou en développement dans votre branche, plus la prochaine rebase sera compliquée et elle subvertit un peu le sens des branches de fonctionnalité, car votre branche n'existe que tant qu'elle n'est pas fusionnée .
Évidemment, la première chose à faire est d'éviter que plusieurs personnes travaillent en premier lieu sur les mêmes fichiers, au moins d'une manière qui entraîne des conflits difficiles. L'ajout de choses dans les énumérations ne pose aucun problème tant qu'un bon format de code est utilisé. Changer le flux de contrôle de différentes manières et déplacer le code est beaucoup plus délicat. Parfois, cela est néanmoins inévitable. Vous devrez poser des questions lors de la résolution de conflits vraiment complexes.
Cela dit, je vois de nombreuses réponses recommandant de fusionner/rebaser sur développer régulièrement. Je serais beaucoup moins enthousiasmé par ce genre de conseils. Votre objectif à ce stade est de rendre le processus de résolution des conflits aussi simple et sûr que possible. Une chose qui va énormément aider avec ce processus est d'avoir autant de tests de régression disponibles immédiatement, y compris les nouveaux qui font partie de votre nouvelle fonctionnalité. Si vous synchronisez votre branche très régulièrement avec develop, vous finirez invariablement par devoir résoudre des conflits pendant que vous avez à moitié terminé d'implémenter réellement votre fonctionnalité. Et cela signifie qu'il sera beaucoup plus difficile d'essayer de comprendre ce que le code est censé faire, car vous n'en avez pas fini. Avant de tenter de fusionner, assurez-vous que votre branche est une unité de changement cohérente. Encore mieux, rebasez-le en un seul commit avant de le fusionner.
J'ai essayé de ne pas entrer dans les mérites de rebase over merge qui est probablement pour une autre question. Dans ce contexte, les outils n'ont pas vraiment d'importance.
Au moment où je suis prêt à fusionner ma branche pour la développer, les autres ont apporté tellement de changements que la résolution des conflits est écrasante
Cela ressemble à un scénario idéal pour programmation par paires !
Plus d'informations sur les avantages et les approches de base:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/
Vous accélérerez naturellement au fil du temps de travailler seul, mais cela peut être intimidant jusqu'à ce moment, et c'est parfois aussi un long parcours. De plus, alors que les gens peuvent apprendre rapidement en étant dans un environnement stressant toujours sous pression pour rattraper leur retard, d'autres qui n'apprennent pas bien sous une pression constante seront gênés.
Au lieu de travailler sur une branche par vous-même et d'essayer de suivre d'autres développeurs qui sont évidemment beaucoup plus rapides que vous, vous travailleriez plutôt directement (même PC) avec un autre développeur. De cette façon, vous obtenez des conseils instantanés et vous obtiendrez probablement des conseils pour accélérer, etc.
Vous auriez trouvé la meilleure approche pour le code particulier de votre projet, car la programmation par paires n'a pas toujours de sens pour certains projets - même si cela a toujours du sens pour apprendre même si vous vous asseyez et regardez quelqu'un de plus expérimenté que vous (tant qu'ils sont un bon développeur, l'expérience ne signifie pas nécessairement qu'ils utilisent de bonnes pratiques).
Assis avec un développeur plus rapide et plus expérimenté peut aider:
- Réduira probablement les conflits de fusion, car travailler avec quelqu'un de plus expérimenté augmentera le temps d'achèvement par opposition à votre travail seul
- Comme ils vous apprendront, il est probable qu'ils seront plus lents qu'ils ne travailleraient seuls, il peut donc y avoir des conflits de fusion et peut donc les résoudre avec quelqu'un de chevronné et donc peut-être prendre quelques conseils pour gagner du temps, etc.
- Vous aider à voir les astuces et les moyens possibles pour être plus rapide (bien que la lenteur soit parfois simplement un manque d'expérience plutôt qu'un manque de bonnes pratiques)
- Peut poser des questions immédiatement lorsque quelque chose n'a pas de sens ou n'est pas clair à 100%
- Le travail 1: 1 est précieux pour l'apprentissage car la personne à qui vous demandez de l'aide comprend déjà le code et le scénario exacts pendant qu'ils y travaillent, sans programmation par paire, vous devez expliquer le code et le scénario, ce qui finit souvent par poser problème et de sorte que vous perdez leur temps/leur attention à obtenir des conseils indispensables
- Apprenez à connaître le processus de réflexion d'une personne plus expérimentée et chevronnée, et avec de bonnes communications, vous apprendrez très certainement de nouvelles choses
Y a-t-il une tactique que je peux utiliser autre que "mieux coder"? J'ai l'intention d'en parler avec mon superviseur la semaine prochaine.
Mon conseil est de discuter de la programmation des paires avec les autres développeurs, puis d'approcher votre superviseur. S'ils sont décents, ils apprécieront votre initiative, ce qui vous donnera plus de chances de présenter les avantages de la programmation par paires (s'ils en ont besoin, la plupart des gens le savent et il est bien connu pourquoi cela aide).
Lorsque vous travaillez dans des fichiers communs, vous ou vos coéquipiers devez résoudre tous les conflits avant la fin de la fusion, donc en premier lieu, ne soyez pas contrarié . Vous faites toujours du travail de projet et soyez fier de votre travail. Maintenant, pour prendre une décision plus intelligente, vous pouvez suivre quelques suggestions ci-dessous.
Divisez les tâches indépendamment:
Avant de commencer votre travail, planifiez et divisez les tâches entières de manière à ce que la tâche assignée à chaque membre de l'équipe soit aussi indépendante et modulaire que possible (pour éviter les conflits potentiels lors du développement). Vous pouvez vous adresser à votre Scrum Leader pour lui assigner des tâches indépendantes lorsque vous êtes débutant.Fusionner les validations fréquentes granulaires:
N'attendez pas la fin de la tâche avant la marge finale. Bien sûr, toutes les tâches plus importantes peuvent être partitionnées en plusieurs sous-tâches. Une meilleure approche consiste donc à fusionner des commits plus petits pour des sous-tâches plus petites en même temps fréquemment afin d'éviter une résolution volumineuse des conflits.Redéfinissez fréquemment votre succursale:
Faites une répétition fréquente de votre succursale locale avec une télécommande. Vous pouvez utiliser la commande ci-dessous pour rebaser fréquemment votre branche locale avec une distante,
git pull --rebase #or git pull --rebase Origin dev #when dev is remote branchC'est jusqu'à présent la commande git la plus utile pour moi dans ma vie de développement.
Travailler en étroite collaboration avec ses coéquipiers:
Si vous avez vraiment besoin de travailler en parallèle avec votre coéquipier dans une tâche commune, veuillez travailler en collaboration. Elle peut attendre un certain temps pour éviter la résolution de conflits complexes pour votre commodité car vous êtes novice et elle est experte.
Soyez habitué aux options git:
Utilisez la puissance des outils de fusion git. Il existe de nombreuses façons pratiques de résoudre les conflits lors de la fusion. Fusionner des stratégies peut parfois aider beaucoup. Soyez habitué et intrépide avec les commandes git.
Vous devez exécuter régulièrement (quotidiennement) la commande 'git fetch' (pas git pull) depuis votre branche de développement. Cela entraînera des modifications engagées par d'autres personnes et les apportera à votre branche de fonctionnalité sans tenter d'intégrer les modifications dans votre branche.
C'est quelque chose dont vous devriez parler au développeur principal (pas nécessairement à votre responsable), car votre entreprise peut avoir ses propres normes ou méthodes recommandées pour gérer ce problème; c'est très courant. N'attendez pas la semaine prochaine - découvrez le processus maintenant et demandez si vous pouvez valider un travail trivial (comme le formatage du code ou l'ajout de commentaires) afin de pouvoir tester le processus.