Présentation des demandes de tirage pour une équipe de 2 personnes - fusionner mes propres demandes?


11

J'introduis git à un membre junior de l'équipe (une coopérative).

Ils sont maintenant à l'aise avec les bases de l'ajout, de l'engagement, de la poussée et de la traction.

Maintenant, je veux les présenter pour extraire les demandes et les branches.

S'ils commencent à faire des demandes de tirage dans les succursales, dois-je faire de même pour mon travail en cours?
Je serai celui qui fusionnera leurs demandes de pull-in. Je ne savais pas si cela aurait le plus de sens pour moi de travailler dans les succursales (généralement une bonne pratique, je sais, mais je suis curieux de connaître la situation spécifique de 2 développeurs avec un junior ) et si c'est le cas, cela signifie que je fusionnerai mes propres branches en maître. Est-ce que je ferais même une demande de pull pour mon travail / branches de toute façon? En règle générale, nous utilisons le flux de travail de base de la fonction Feature Branch de github pour ces modifications:
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

Y a-t-il un intérêt à utiliser les demandes de tirage sur mon propre référentiel si je suis le seul développeur? est utile mais pas tout à fait aussi spécifique.

Quel est le flux de travail avec 2 personnes sur un projet semble aussi plus général

et

Dois-je ouvrir les demandes de tirage d'une succursale sur le référentiel officiel ou ma fourchette? semble plus sur les fourches.

Réponses:


19

Non. Vous ne devez pas fusionner vos propres demandes d'extraction. Ce qui est bon pour l'oie est bon pour le jars. La fusion de vos propres demandes de tirage crée un mauvais précédent pour notre développeur junior. Cela signifie également que personne d'autre ne regarde votre code. Peu importe notre niveau de responsabilité, nous commettons tous des erreurs et écrivons de temps à autre du mauvais code. Apprenez à votre junior comment les révisions de code fonctionnent de l'autre côté en lui faisant réviser et fusionner votre travail.

Il n'a peut-être pas le même œil que vous, mais cela lui permettra de s'habituer au processus de la part de l'examinateur et il peut vous surprendre et attraper quelque chose de stupide que vous avez fait. Au minimum, cela vous donnera une indication des morceaux de code qui sont évidents pour vous, qui ne sont pas évidents pour lui. Cela présente un double avantage.

  1. Vous apprenez tous les deux où votre junior doit concentrer ses activités d'apprentissage.
  2. Vous apprenez où vous êtes plus intelligent que vous ne devriez l'être.

6
L'autre énorme avantage des revues de code est qu'au moins deux personnes ont vu, connaissent et ont eu la chance de poser des questions sur chaque changement de code avant qu'il n'entre. Même si le développeur junior ne sait pas quoi chercher, il est garanti d'apprendre quelque chose de tout cela.
Ixrec
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.