Github : Différence entre versions

De WikiOpenTruc
Aller à : navigation, rechercher
(Pull Request)
(Glossaire)
Ligne 91 : Ligne 91 :
 
Jargon spécifique employé dans les commentaires/issues :
 
Jargon spécifique employé dans les commentaires/issues :
  
* CI /CD : Continuous Integration / Continuous Deployment
+
* CI /CD : Continuous Integration / Continuous Deployment, se traduit eg par le fait que, à peine une PR effectuée, un outil va déjà réaliser un build pour voir si ça gaze. C'est toujours ça de moins à faire pour l'administrateur.
  
 
* Concept ACK - Agree with the idea and overall direction, but haven't reviewed the code changes or tested them.
 
* Concept ACK - Agree with the idea and overall direction, but haven't reviewed the code changes or tested them.
Ligne 107 : Ligne 107 :
 
* xxxACK et Nit concernent a priori uniquement les PR (Pull Request) et sont donnés en commentaires
 
* xxxACK et Nit concernent a priori uniquement les PR (Pull Request) et sont donnés en commentaires
  
 +
* PR : Pull Request = demande d'intégration de code ajouté, ou modifié
 
<br>
 
<br>
  

Version du 9 juillet 2019 à 19:36

Github.com

  • Juin 2018 : Github racheté par Microsoft. ... on a du mal à voir ça comme une bonne nouvelle. -> Gitlab
  • la principale implémentation de git sur internet
  • https://github.com = le dépôt principal sur internet pour les programmes open-source gérés par git. (github lui-même ... n'étant pas open-source !)
  • gratuit pour les projets open-source, > 14 millions de repositories


Dans un projet géré sur github, il y a :

  • une branche maîtresse (master), avec un ou plusieurs mainteneurs
  • éventuellement des branches secondaires qui peuvent servir à plusieurs choses:
    • branches à la debian : stable, verylast, testing, unstable, etc
    • branches éphémères, qui n'ont vocation qu'à implémenter un petit changement, avant merge dans un master. Sitôt mergée, la branche n'a plus d'utilité et est effacée
  • des clones dispersés un peu partout

L'enjeu, sur un site comme github (250 employés en 2014), c'est de permettre à tout ce beau monde de travailler ensemble en bonne intelligence, sur des projets qui souvent comptent des centaines voire des milliers de fichiers.

Beaucoup de dépôts ont juste une branche master car cela suffit dans la majorité des cas.

Il y a évidemment des projets qui maintiennent simultanément plusieurs branches ... mais il faut évidemment vraiment en avoir l'utilité, car c'est du boulot en plus (et un peu de confusion parfois en plus). En même temps, une branche master + une branche testing c'est aussi de la sécurité en plus.


Tips

Certains projets sur github sont de gros projets, avec :

  • beaucoup de sous-répertoires
  • mais aussi des branches

Si on ne trouve pas un fichier ... c'est peut-être tout simplement car il se trouve sur une autre branche.

Github.com est un site riche, avec plein de fonctionnalités. Donc, pour réaliser un truc, il y a souvent plusieurs façons possibles de procéder. Il n'y a pas forcément une procédure gravée dans le marbre.

On peut éditer certains fichiers dans github.com. Pour enregistrer les modifications, il faut passer par preview


écosystème

  • Maven : c'est une espèce de make, pour java. Soft Apache. Dispo dans le dépôt officiel Debian.
  • Gradle : idem. Dispo dans le dépôt officiel Debian.

Les projets qui font appel à ces outils ont bien sûr des fichiers de paramètres relatifs à ces outils. Ces fichiers eux-mêmes n'ont rien à voir avec git ou github.

  • Netlify : a priori c'est surtout pour des pages statiques, ie typiquement de la documentation. à chaque fois que la doc est modifiée sur son répertoire github, aussi sec les nouveaux fichiers sont uploadés dans leur répertoire/site/sous-domaine. Les structures des répertoires sources et destination sont identiques, ce qui permet d'utiliser des liens relatifs.

Github peut être aussi lié à des plate-formes de communication collaborative. Par exemple Slack, où les commentaires sur github peuvent être instantanément reproduits.


Issues

  • les issues closed sont toujours closed avec une icône rouge (quel que soit le sort).


Pull Request

On considère ici surtout les PR vers le projet originel.

  • pour de la documentation, il est évident que au plus une PR inclus de modifications, au plus la probabilité de refus augmente. 9 modifications pertinentes + 1 modification non-pertinente => refus de la PR globale. Donc il vaut mieux soumettre ses modifications par paquets de taille raisonnable. On peut aussi ne pas mélanger les modifications indiscutables (typos, fautes d'orthographe, etc) avec les modifications plus sensibles.
  • si ça se termine bien (ACK), on a droit à une petite icône violette. Si ça se termine mal (NACK), on a droit à une petite icône rouge.
  • pour se faciliter les PR sur Github, l'idéal est d'y avoir un compte à soi, et de forker la repository concernée. Ensuite, il est souvent recommandé de créer une branche (éphémère) spécifiquement dédiée à la PR qu'on souhaite effectuer (et nommée en conséquence). C'est à partir de cette branche qu'on effectuera la PR. Si la PR est acceptée, ie intégrée au projet principal, la branche a accompli son office et peut être supprimée. (Un développeur actif peut avoir des dizaines de branches).
  • à noter que, eg pour de la documentation, quand on modifie un fichier qui fait déjà l'objet d'une PR (eg suite à des demandes de changements), si un outil comme netlify est installé cet outil va réagir, eg envoyer des notifications sur slack, etc.


Glossaire

Jargon spécifique employé dans les commentaires/issues :

  • CI /CD : Continuous Integration / Continuous Deployment, se traduit eg par le fait que, à peine une PR effectuée, un outil va déjà réaliser un build pour voir si ça gaze. C'est toujours ça de moins à faire pour l'administrateur.
  • Concept ACK - Agree with the idea and overall direction, but haven't reviewed the code changes or tested them.
  • utACK (untested ACK) - Reviewed and agree with the code changes but haven't actually tested them.
  • Tested ACK - Reviewed the code changes and have verified the functionality or bug fix.
  • ACK - A loose ACK can be confusing. It's best to avoid them unless it's a documentation/comment only change in which case there is nothing to test/verify; therefore the tested/untested distinction is not there.
  • NACK - Disagree with the code changes/concept. Should be accompanied by an explanation.
  • Nit refers to trivial, often non-blocking issues, donc c'est suivi de la liste des petits soucis visés.
  • xxxACK et Nit concernent a priori uniquement les PR (Pull Request) et sont donnés en commentaires
  • PR : Pull Request = demande d'intégration de code ajouté, ou modifié


Pages connexes


Liens