Y a-t-il un intérêt à utiliser les pull pulls sur mon propre référentiel si je suis le seul développeur?
J'ai donc commencé avec un vrai projet à moi sur GitHub et les choses vont plutôt bien et les idées coulent beaucoup plus vite que je ne le pensais au départ. Afin de garder les choses organisées, j'ai configuré certaines branches afin de pouvoir développer différentes fonctionnalités séparément.
Maintenant, quand je pousse ma branche vers GitHub, j'ai cette section où j'ai deux boutons: Pull Request et Compare avec le nom de la branche vers laquelle j'ai récemment poussé. Je comprends le but du bouton Compare mais je ne comprends pas pourquoi je voudrais créer une pull request sur mon propre référentiel.
Quelqu'un peut-il m'expliquer pourquoi je ferais ça? Est-il utile de faire une demande d'extraction sur mon propre référentiel si je suis le seul développeur?
Pour de nombreux développeurs individuels (peut-être la plupart) travaillant seuls, la création de demandes d'extraction n'est probablement pas la peine. Cependant, je peux penser à au moins une raison potentielle de le faire:
Les demandes d'extraction peuvent être utilisées pour suivre plus facilement l'historique de votre projet. Une demande d'extraction a un ID de problème auquel il est possible de se référer à partir des messages de validation et dans un journal des modifications, ce qui vous permet de revenir facilement en arrière et de trouver le point de fusion et l'ensemble de validations fusionnées pour une modification particulière, sans avoir à conserver votre fonctionnalité. branches indéfiniment.
Par exemple, dans Pioneer (plug sans vergogne), lorsque nous fusionnons une demande d'extraction, nous ajoutons un élément au changelog , avec une description d'une ligne de la modification et un référence à l'ID de demande d'extraction. Bien sûr, Pioneer a plusieurs développeurs, mais le même mécanisme pourrait être utile pour un développeur travaillant seul.
Cela peut être moins utile si vous décidez de vous en tenir à un historique de validation linéaire (en rebasant vos branches de fonctionnalités avant la fusion, afin que la fusion puisse toujours être effectuée en tant qu'avance rapide), et si vous êtes très discipliné à propos de l'édition et de l'écrasement de votre valide avant de fusionner avec master, car dans ce cas, les messages de validation individuels peuvent être utilisés comme journal des modifications en eux-mêmes.
Les demandes d'extraction sont créées afin que quelqu'un puisse examiner le travail, faire des commentaires, des suggestions, effectuer ou demander des modifications, puis fusionner le code à maîtriser.
Dans votre cas, c'est quelqu'un.
En tant que développeur unique, vous devez toujours revoir votre propre travail, le refactoriser et le fusionner pour le maîtriser lorsque vous êtes prêt.
Une approche que j'utilise beaucoup est d'essayer de "mettre un autre chapeau", "d'essayer d'autres personnages". Alors asseyez-vous un petit moment et placez-vous dans la situation de: débutant dans le groupe; Développeur débutant; collègue que vous avez respecté dans le passé, etc. Essayez de le regarder à travers leurs yeux et essayez de penser simplement à ce que vous pourriez faire pour rendre le changement plus évident, mieux écrit avec des noms encore meilleurs qui évitent autant que possible la connaissance tribale et du domaine .
Ainsi, comme vous l'avez indiqué, vous devez travailler dans des branches lorsque vous souhaitez séparer des fonctionnalités et des modifications qui ne sont pas prêtes pour le master. Vous pouvez faire tout cela dans les succursales (vous n'avez même pas besoin de tirer des demandes pour les gérer si vous effectuez les tâches PR de toute façon, mais cela peut vous fournir une structure utile).
De plus, je trouve parfois que ma modification ne fonctionne pas, mais plutôt que l'horreur d'essayer de la retirer du maître, peut-être maintenant mélangée avec d'autres changements de maître, je peux tout faire dans une branche que je peux ensuite ignorer/supprimer s'il commence à mal tourner. C'est un énorme avantage.
Ainsi, vous devriez travailler dans des branches et pas vous engager directement à master jusqu'à ce que vous décidiez de fusionner la branche entière.
Ce sont des directives - et non des règles - à suivre. Je les brise intentionnellement parfois. Par exemple, hier, j'ai commis une correction de faute de frappe sur master.
Il semble que vous ayez des succursales distantes ainsi que des succursales locales. Si vous trouvez trop les frais généraux de ce flux de travail, vous pouvez toujours travailler sur différentes fonctionnalités à l'aide de branches locales sans les pousser.
Il s'agit essentiellement de faire ce qui fonctionne pour vous. Travailler avec des branches est un énorme avantage pour git, et github rend cela très facile, mais en tant que développeur seul, il n'y a pas grand besoin d'utiliser le modèle de demande de pull et s'engager directement sur master devrait fonctionner très bien. Lorsque votre projet finit par devenir incroyablement réussi et que des dizaines ou des centaines de développeurs y travaillent, vous constaterez que recevoir des demandes d'extraction de leurs fourches est un excellent moyen de garder une trace du projet.
Les demandes de tirage sont généralement utilisées pour des révisions de code ou des contributions d'utilisateurs avec leur propre fork du projet - pour un développeur unique sur un projet, je ne vois pas vraiment de raison.
La raison pour laquelle je le fais, c'est que c'est un moyen pratique de s'assurer que tous les contrôles automatisés réussissent (il compile, il a un formatage correct, les tests unitaires passent ...).
Je n'ai pas nécessairement besoin de passer tous les contrôles pour chaque validation, mais je veux que le chef de la branche principale passe toujours les contrôles. Je pense que les demandes de tirage sont le moyen le plus simple (peut-être pas le seul).
Plus généralement, c'est un moyen de connecter des crochets pour effectuer les modifications. Les tests en sont un exemple; @John a mentionné la création de notes de publication comme un autre exemple.