En fonction de votre historique avec le contr\u00f4le de code source, la mani\u00e8re dont vous travaillez avec une base de code, faites des commits, etc., varie.<\/p>\n
De plus, selon que vous utilisez Git<\/a>, Subversion<\/a>, Mercurial<\/a>, etc., dictez \u00e9galement la fa\u00e7on dont vous g\u00e9rez votre code.<\/p>\n Mais si vous \u00eates quelqu’un qui travaille avec Git (que je sais que beaucoup de gens dans WordPress commencent \u00e0 utiliser de plus en plus presque quotidiennement), il y a quelques petites choses que je recommande de faire pour aider \u00e0 g\u00e9rer les changements, en particulier avec une \u00e9quipe plus g\u00e9rable.<\/p>\n Master doit \u00eatre utilis\u00e9 sp\u00e9cifiquement pour le code pr\u00eat pour la production et le d\u00e9ploiement. Ce n’est pas votre branche de travail, ce n’est pas votre branche de travail.<\/p>\n D’une mani\u00e8re g\u00e9n\u00e9rale, c’est l\u00e0 que toutes les demandes d’extraction sont fusionn\u00e9es.<\/p>\n Chaque fois que vous avez une collection de t\u00e2ches, de probl\u00e8mes ou de jalons, cr\u00e9ez une branche et assurez-vous que tout ce sur quoi vous travaillez est li\u00e9. Par exemple, vous ne voulez pas faire de travail de base de donn\u00e9es et JavaScript dans vos demandes d’extraction.<\/p>\n M\u00eame si vous travaillez uniquement sur le travail frontal, vous devrez peut-\u00eatre le diviser en branches plus petites. Cela facilite les r\u00e9visions de code et am\u00e9liore les demandes d’extraction<\/a>.<\/p>\n Ceci est tr\u00e8s similaire au titre pr\u00e9c\u00e9dent, mais l’id\u00e9e de cr\u00e9er de petits PR est bien plus productive que de cr\u00e9er des pull requests plus longues.<\/p>\n Mais qu’est-ce qui constitue un bon PR?<\/p>\n En ce qui me concerne, une bonne pull request fera un petit ensemble de choses\u00a0:<\/p>\n Cela dit, il y a probablement plus de choses que vous pouvez faire, mais ce sont les choses que j’ai trouv\u00e9es les plus utiles (et je serais d\u00e9\u00e7u de dire que je n’ai pas appris certaines de ces choses de mon \u00e9quipe<\/a> ).<\/p>\n Toujours.<\/p>\n Mais ce sont quelques \u00e9l\u00e9ments que j’ai trouv\u00e9s de plus en plus utiles, en particulier lors du suivi des modifications, du travail avec les autres et du traitement des demandes d’extraction (\u00e0 la fois de ceux avec qui je travaille et de ceux qui contribuent \u00e0 des projets open source).<\/p>\n Enfin, aucune de ces choses n’est prescriptive. Il y a une courbe d’apprentissage (par exp\u00e9rience), mais je recommande d’en essayer quelques-unes si ce n’est pour aucune autre raison que de voir si cela n’am\u00e9liore pas votre flux de travail.<\/p>\n M\u00eame si ce n’est qu’un tout petit peu.<\/p>\nConseils pour un flux de travail GitHub am\u00e9lior\u00e9<\/h2>\n
1 Ne vous engagez pas \u00e0 ma\u00eetriser<\/strong><\/h3>\n
2 Essayez de toujours cr\u00e9er des branches<\/strong><\/h3>\n
3 Regroupez votre travail<\/strong><\/h3>\n
4 G\u00e9n\u00e9rer de petits PR<\/strong><\/h3>\n
\n
5 Donnez de bons d\u00e9tails dans votre PR<\/strong><\/h3>\n
\n
Y a-t-il plus de choses ?<\/h2>\n