Github : Différence entre versions

De WikiOpenTruc
Aller à : navigation, rechercher
(Pages connexes)
(Glossaire)
Ligne 59 : Ligne 59 :
  
 
<br>
 
<br>
 +
 +
==Issues==
 +
 +
* les issues closed sont toujours closed avec une icône rouge (quel que soit le sort).
 +
 +
<br>
 +
 +
==Pull Request==
 +
 +
* 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.
 +
 +
<br>
 +
  
 
==Glossaire==
 
==Glossaire==

Version du 6 juin 2018 à 10:02

Github.com

  • Juin 2018 : Github rachété 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 aura toujours :

  • une branche maîtresse (master), avec un ou plusieurs mainteneurs
  • éventuellement des branches secondaires un peu comme les versions debian : stable, verylast, testing, unstable, etc
  • 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.

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

  • 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.



Glossaire

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

  • 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.


Pages connexes


Liens