5 idées pour un flux de travail GitHub amélioré
En fonction de votre historique avec le contrôle de code source, la manière dont vous travaillez avec une base de code, faites des commits, etc., varie.
De plus, selon que vous utilisez Git, Subversion, Mercurial, etc., dictez également la façon dont vous gérez votre code.
Mais si vous êtes quelqu’un qui travaille avec Git (que je sais que beaucoup de gens dans WordPress commencent à utiliser de plus en plus presque quotidiennement), il y a quelques petites choses que je recommande de faire pour aider à gérer les changements, en particulier avec une équipe plus gérable.
Conseils pour un flux de travail GitHub amélioré
1 Ne vous engagez pas à maîtriser
Master doit être utilisé spécifiquement pour le code prêt pour la production et le déploiement. Ce n’est pas votre branche de travail, ce n’est pas votre branche de travail.
D’une manière générale, c’est là que toutes les demandes d’extraction sont fusionnées.
2 Essayez de toujours créer des branches
Chaque fois que vous avez une collection de tâches, de problèmes ou de jalons, créez une branche et assurez-vous que tout ce sur quoi vous travaillez est lié. Par exemple, vous ne voulez pas faire de travail de base de données et JavaScript dans vos demandes d’extraction.
3 Regroupez votre travail
Même si vous travaillez uniquement sur le travail frontal, vous devrez peut-être le diviser en branches plus petites. Cela facilite les révisions de code et améliore les demandes d’extraction.
4 Générer de petits PR
Ceci est très similaire au titre précédent, mais l’idée de créer de petits PR est bien plus productive que de créer des pull requests plus longues.
- Cela aide lorsque vous avez besoin de demander une révision de code, car cela donne à votre ou vos coéquipiers un moyen plus simple de gérer les révisions de code et d’offrir des commentaires.
- Il maintient le journal des modifications léger et aide à fournir un rapport détaillé de ce que fait le lot de code spécifique.
Mais qu’est-ce qui constitue un bon PR?
5 Donnez de bons détails dans votre PR
En ce qui me concerne, une bonne pull request fera un petit ensemble de choses :
- Détaillez, en une phrase ou deux, ce à quoi la personne qui examine vos modifications doit s’attendre.
- Associez le PR au ticket, à la carte de gestion de projet (ou à tout ce qu’ils appellent dans votre système),
- Répertoriez des versions plus courtes des messages de validation pour faciliter au maximum la tâche de votre pair examinateur.
Cela dit, il y a probablement plus de choses que vous pouvez faire, mais ce sont les choses que j’ai trouvées les plus utiles (et je serais déçu de dire que je n’ai pas appris certaines de ces choses de mon équipe ).
Y a-t-il plus de choses ?
Toujours.
Mais ce sont quelques éléments que j’ai trouvés de plus en plus utiles, en particulier lors du suivi des modifications, du travail avec les autres et du traitement des demandes d’extraction (à la fois de ceux avec qui je travaille et de ceux qui contribuent à des projets open source).
Enfin, aucune de ces choses n’est prescriptive. Il y a une courbe d’apprentissage (par expérience), mais je recommande d’en essayer quelques-unes si ce n’est pour aucune autre raison que de voir si cela n’améliore pas votre flux de travail.
Même si ce n’est qu’un tout petit peu.