Github : Différence entre versions

De WikiOpenTruc
Aller à : navigation, rechercher
(Liens)
(Liens)
Ligne 112 : Ligne 112 :
  
 
* https://framagit.org/ le site gitlab de framasoft
 
* https://framagit.org/ le site gitlab de framasoft
 +
** https://docs.framasoft.org/fr/gitlab/
  
 
<br>
 
<br>

Version du 15 juin 2018 à 19:05

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.

  • 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

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


Glossaire

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

  • CI /CD : Continuous Integration / Continuous Deployment
  • 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