| marp |
|---|
true |
- Serveur distant
- Gestion d'équipe et de projets
- Comptes utilisateurs
- Comptes organisations
- Équipes aux niveaux repository et organisations
- Gestion de bug et de tickets (Issues)
- Gestion de fusion de branche et de "review"
- Un bug : on donne alors un titre au bug
- si c'est dans le cadre d'un logiciel/d'une application/d'un site, on donne la démarche pour le reproduire
- on pense à donner les fichiers concernés par le bug
- on essaye de décrire au mieux le problème. Même si c'est sur notre propre dépôt.
- Sinon, on oublie le bug, on revient deux mois plus tard, on sait plus ce que c'est.
- une nouveauté : on veut une nouvelle fonctionnalité, un nouvel ensemble de données
- on décrit correctement ce que l'on veut, de manière à pouvoir transférer la charge ou s'en occuper soi-même plus tard
- une discussion : on essaye de comprendre un morceau de code, etc.
- Les issues peuvent être attribuées à des membres du dépôt : si je travaille avec @vincentjolivet, et qu'un bug le concerne, je peux lui attribuer en tant que membre. Sinon, en voyant un bug qui me concerne, je peux me l'attribuer.
- Les issues peuvent avoir des labels. Une série de labels par défaut existe, mais on peut tout à fait en ajouter à ses propres dépôts.
- Les issues peuvent faire l'objet de regroupement dans des projects (sans deadline), des milestones (objectifs de sortie d'une nouvelle version).
{height=60%}
{height=60%}
- Les données de https://github.com/chartes/elec vous intéresse. Mais vous aimeriez changer une partie des données : ne conserver que les testaments de poilu et supprimer les éléments qui ne correspondent pas à vos besoins.
- À ce moment-là, on va réaliser un fork du repository sur son propre compte. On obtient ainsi les droits d'écritures sur le repository tout en gardant l'ensemble de son historique. On travaille sur ce repository ensuite localement, comme on travaillerait avec n'importe quel repository.
- Note: Si l'on fait des modifications sur un dépôt d'une autre personne, il est plus respectueux de faire un fork que de télécharger et de créer un nouveau dépôt.
- Une pull request (Vocabulaire de github) est une demande d'autorisation de contribution à un dépôt.
- Une pull request se fait entre deux branches, comme un merge. Cependant, cela peut être deux branches de deux forks.
- Contribuer à un repository ?
- Non seulement j'aide la personne et les utilisateurs du repository
- Mais en plus j'apparais sur l'historique
- Je remarque une erreur dans les métadonnées d'un document
- J'ouvre une issue qui explique le problème (Typo dans le fichier X, etc.)
- Parce que je veux être encore plus utile, je veux proposer la modification pour que le propriétaire n'ait pas à faire la correction lui-même
- Je fais un fork du dépôt du cours ( https://github.com/ponteineptique/cours-git )
- Je crée une branche spécifique et je rentre dessus
- Tips : quand on fait une branche pour un objectif particulier, on l'appelle du nom de l'issue pour se souvenir de pourquoi on a créé cette branche
- Je fais la modification et je la commit
- Je push
- Je fais une pull request sur le repository d'origine
- Aller sur https://github.com/PonteIneptique/canonical-greekLit
- Prendre un dossier auteur de https://github.com/PonteIneptique/canonical-greekLit/tree/master/data (Identifié par tlg**** )
- Dans ce dossier, ouvrir le fichier cts.xml
- Suivant les bonnes pratiques (issues, fork, pull request), proposer la traduction du nom de l'auteur
- Bonus: Ajouter l'identifiant Wikidata
...
<cpt:structured-metadata
xmlns:cpt="http://purl.org/capitains/ns/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:identifier>https://www.wikidata.org/wiki/Q2098</dc:identifier>
</cpt:structured-metadata>
</ti:textgroup>