12 fonctionnalités étonnantes de GitHub

Pour ma vie, je n'arrive à penser à aucune introduction, alors...

#1 Modification du code sur GitHub.com

Je vais commencer par ce que je pense que tout le monde sait déjà (même si personnellement, je n’en avais aucune idée il y a une semaine). Lors de la visualisation d'un fichier texte sur GitHub, dans n'importe quel référentiel, vous pouvez voir un petit crayon en haut à droite. Si vous cliquez dessus, vous pouvez modifier ce fichier. Une fois terminé, cliquez sur Proposer une modification de fichier et GitHub créera un fork et une Pull Request. Incroyable, n'est-ce pas ? Il crée lui-même la fourchette ! Il n'est pas nécessaire de créer et de télécharger le code sur vous-même, d'apporter des modifications localement et de le renvoyer à GitHub avec une Pull Request. Très pratique si vous devez apporter des modifications minimes. pas tout à fait une vraie Pull Request

#2 Insérer des images

Les descriptions des problèmes ne se limitent pas aux seuls commentaires textuels. Saviez-vous que vous pouvez coller des images directement depuis le presse-papiers ? Une fois collé, vous le verrez téléchargé (sur le cloud, sans aucun doute) et transformé en balisage pour afficher l'image. Gracieux!

#3 Formatage du code

Si vous avez besoin d'écrire un bloc de code, commencez par trois backticks et GitHub essaiera de deviner dans quel langage de programmation vous écrivez. Mais si vous publiez un morceau de code dans un langage de programmation comme Vue, Typescript ou JSX, vous pouvez spécifier explicitement le langage afin que la coloration syntaxique soit correcte. Notez le ```jsx sur la première ligne : ...garantissant le bon affichage de l'extrait de code : (Cela s'applique également à Gist, d'ailleurs. Si vous spécifiez l'extension .jsf pour un Gist, la syntaxe JSF sera mise en surbrillance). Voici une liste de toutes les syntaxes prises en charge .

#4 Résoudre les problèmes en utilisant des « mots magiques » dans les requêtes Pull

Supposons que vous créiez une Pull Request qui résout le problème n°234. Vous pouvez insérer le texte « corrige le problème n° 234 » dans la description de votre demande (ou n'importe où dans tout commentaire de demande de modification). Après cela, la fusion de la Pull Request clôturera « automatiquement » le problème. Cool, n'est-ce pas ? Voici plus d'informations à ce sujet dans la documentation .

#5 Lien vers les commentaires

Avez-vous déjà eu besoin de créer un lien vers un commentaire spécifique sans savoir comment le faire ? Cette époque est révolue depuis longtemps car je vais vous confier un secret : pour créer un lien vers un commentaire, il vous suffit de cliquer sur la date/heure à côté du titre. Regardez, Gaearon a maintenant une photo !

#6 Lien de code

Vous souhaitez donc créer un lien vers une ligne de code spécifique. Dans ce cas, essayez ceci : Cliquez sur le numéro de ligne à côté du code souhaité dans le fichier ouvert. Waouh, tu vois ? L'URL a changé, le numéro de ligne y est désormais visible ! Si vous maintenez la touche MAJ enfoncée et cliquez sur un autre numéro de ligne, alors voilà ! – L'URL changera à nouveau et la plage de lignes sera mise en surbrillance. Cette URL pointera désormais vers ce fichier et cette plage de lignes. Mais attendez, cela pointe vers le fil de discussion actuel. Et si le fichier change ? Vous avez probablement besoin, dans ce cas, d'un lien permanent vers le fichier dans son état actuel. Je suis très paresseux, alors j'ai pris une capture d'écran de tout ce qui précède : Au fait, à propos des URL...

#7 Utiliser l'URL GitHub comme ligne de commande

La navigation dans GitHub à l'aide de l'interface utilisateur est organisée de manière très pratique. Mais parfois, pour accéder à un emplacement spécifique, il est plus rapide de simplement le saisir dans l'URL. Par exemple, si je veux accéder à une branche sur laquelle je travaille et voir comment elle se compare à master, je peux simplement taper /compare/branchname après le nom du référentiel. Cela m'amènera à la page de comparaison pour cette branche : Mais ce sont des différences par rapport à la branche master, mais si j'ai déjà travaillé avec la branche d'intégration, je peux saisir /compare/integration-branch...my-branch dans l'URL Pour les amateurs de raccourcis clavier : CTRL+L ou CMD+L déplace le curseur vers la barre d'URL (au moins dans les navigateurs Chrome et Firefox). Ceci, combiné à la saisie semi-automatique du navigateur, facilite grandement la navigation entre les branches. Conseil de pro : utilisez les flèches pour parcourir les suggestions de saisie semi-automatique de Chrome et appuyez sur MAJ+SUPPRIMER pour supprimer des éléments de l'historique (par exemple, après la fusion d'une branche). (Je ne sais pas s'il serait plus facile de lire ces touches de raccourci si j'y mettais un espace, comme SHIFT + DELETE. Mais techniquement, « + » n'en fait pas partie, donc je n'aime pas cette option. C'est à cause de choses comme ça, je ne dors pas la nuit, Rhonda.)

#8 Créer des listes de problèmes

Voulez-vous une case à cocher dans la description de votre problème ? Et voulez-vous qu’une barre astucieuse comme « 2 sur 5 » apparaisse lorsque vous consultez un problème dans la liste ? Aucun problème! Vous pouvez créer des cases à cocher interactives en utilisant la syntaxe suivante :

• [ ] Largeur de l'écran (entier)
• [x] Assistance aux techniciens de service
• [x] Récupérer le support
• [ ] Prise en charge des boîtes flexibles CSS
• [ ] Éléments personnalisés

Syntaxe : espace, trait d'union, espace, crochet ouvrant, espace (ou x), crochet fermant, espace et quelques mots. Après cela, vous pouvez réellement cocher/décocher ces boutons ! Pour une raison quelconque, cela me semble être une sorte de magie technique. Vous pouvez cocher les cases ! Et en même temps le texte original change ! C'est effrayant de penser à ce qu'ils vont proposer ensuite. Oh, et si ce problème se trouve dans le panneau du projet, alors la progression y sera également affichée : Si vous ne comprenez pas ce que j'entends par « panneau de projet », lisez ci-dessous. Juste quelques centimètres plus bas sur cette page.

#9 Panneaux de projet dans GitHub

Pour les grands projets, j'ai toujours utilisé Jira. Et pour mes projets personnels, j'ai toujours utilisé Trello. J'aime beaucoup ces deux outils. Lorsque j'ai appris il y a quelques semaines que GitHub proposait sa propre option, directement dans l' onglet Projets du référentiel, j'ai pensé qu'il serait logique de dupliquer l'ensemble des tâches avec lesquelles je travaille déjà dans Trello. Il n'y a rien de drôle ici. Et maintenant la même chose dans le projet GitHub : Petit à petit, vos yeux s'habitueront à l'image à faible contraste Par souci de rapidité, j'ai ajouté tout ce qui précède sous forme de notes, ce qui signifie qu'il ne s'agit pas de « vrais » problèmes GitHub. Mais la puissance de la gestion des problèmes dans GitHub réside dans son intégration avec le reste du référentiel : il est donc probablement préférable d'ajouter les problèmes existants du référentiel au tableau de bord. Cliquez sur Ajouter des cartes dans le coin supérieur droit et recherchez ce que vous souhaitez ajouter. C'est là qu'une syntaxe de recherche spéciale s'avère utile : par exemple, tapez is:pr is:open et vous pouvez faire glisser n'importe quelle Pull Request ouverte vers le panneau, ou label:bug si vous devez corriger des erreurs. Vous pouvez également convertir des notes existantes en problèmes. Et enfin, à partir du formulaire de problème existant, ajoutez-le au projet dans le panneau de droite. Il ira dans la liste de tri de ce panneau de projet, vous pourrez donc choisir dans quelle colonne le placer. Lorsque la description d’une « tâche » est dans le même référentiel que le code implémentant cette tâche, c’est très (très) pratique. Cela signifie que dans de nombreuses années, vous serez en mesure d'exécuter git blâme sur une ligne de code et de comprendre l'intégralité du problème qui a conduit à cette ligne, sans avoir à tout retrouver dans Jira/Trello/ailleurs.

Défauts

Au cours des trois dernières semaines, j'ai essayé de tout faire dans GitHub au lieu de Jira (sur un petit projet, une sorte de style Kanban) et j'ai adoré. Mais je ne peux pas imaginer cela pour un projet Scrum où la vitesse de développement, etc., doit être évaluée et calculée correctement. La bonne nouvelle est que les projets GitHub ont si peu de « fonctionnalités spéciales » que le passage à un autre système ne prendra pas beaucoup de temps. Alors essayez-le et voyez à quel point vous l’aimez. Je ne sais pas à quel point c'est important, mais j'ai entendu parler de ZenHub et je l'ai ouvert pour la première fois il y a 10 minutes. Il s'agit essentiellement d'une extension de GitHub où vous pouvez évaluer les problèmes et créer des « épopées » et des dépendances. Il existe des graphiques de vitesse de développement et d'épuisement professionnel ; On dirait que c'est juste une chose incroyable. Lectures complémentaires : documentation GitHub sur les projets.

#10 Gwiki

Pour un ensemble de pages non structurées, comme Wikipédia, le wiki GitHub (que j'appellerai désormais Gwiki) est génial. Pour un ensemble structuré de pages – par exemple, comme votre documentation – pas tellement. Il n'y a aucun moyen d'indiquer que « cette page est un enfant de celle-là » ; il n'y a pas de choses aussi pratiques que les boutons « Section suivante » et « Section précédente ». Hansel et Gretel se perdraient certainement ici, car il n'y a pas non plus de «fil d'Ariane» (opérateurs de débogage spéciaux - environ trans.). (Note de l'auteur : avez-vous lu cette histoire ? C'est tout simplement inhumain. Deux jeunes voyous tuent une pauvre vieille dame affamée, la brûlant vive dans son propre four . Et bien sûr, laissant un désordre complet que personne ne peut comprendre. Je pense que c'est pour ça les jeunes d'aujourd'hui sont si sensibles que l'enfer – les histoires lues aux enfants à l'heure du coucher ne sont pas assez cruelles !) Passons à autre chose – pour essayer Gwiki pour de vrai, j'ai entré quelques pages de NodeJS comme pages wiki, puis j'ai créé un fichier wiki personnalisé. barre latérale pour simuler la structure réelle du site. Cette barre latérale est toujours là, même si la page actuelle n'est pas mise en surbrillance. Les liens devront être entretenus manuellement, mais dans l'ensemble, tout fonctionne bien. Si vous le souhaitez, vous pouvez jeter un oeil : Cela peut difficilement rivaliser avec quelque chose comme GitBook (qui est utilisé dans la documentation Redux ) ou un site Web sur mesure. Mais cela représente déjà 80% et tout est bien dans votre référentiel. Je suis juste fan de ça. Je suggère que si vous êtes devenu trop grand pour le fichier README.md unique et que vous avez besoin de plusieurs pages différentes pour les manuels d'utilisation ou une documentation plus détaillée, il est logique de s'en tenir à Gwiki. Si le manque de structure/navigation vous dérange, passez à autre chose.

#11 Pages GitHub

Vous savez peut-être déjà que les pages GitHub peuvent être utilisées pour héberger un site Web statique. Et si vous ne le saviez pas, alors vous le savez maintenant. Cependant, cette section est dédiée à un sujet plus précis : utiliser Jekyll pour créer un site internet. Dans sa forme la plus simple, GitHub Pages + Jekyll peut restituer le fichier README.md en utilisant un joli thème. Par exemple, jetez un œil à ma page Lisez-moi de about-github : Si vous cliquez sur l'onglet paramètres de ce site GitHub, activez les pages GitHub et sélectionnez le thème Jekyll... Nous obtiendrons ensuite une page dans le style du thème Jekyll : Vous pouvez ensuite créer un site statique complet basé principalement sur des fichiers de balisage facilement modifiables, transformant essentiellement GitHub en CMS. Bien que je ne l'aie pas réellement utilisé, c'est ainsi que les sites Web sont construits à l'aide du framework Bootstrap à l'aide de React, il n'y a donc rien de terrible à cela. Je note que Ruby doit tourner sur la machine locale (les utilisateurs Windows échangeront ici des regards compréhensifs et iront dans l'autre sens, les utilisateurs macOS diront : "C'est quoi le problème, où vas-tu ? Ruby est une plateforme universelle ! Il y a aussi un GEMS système de gestion de paquets ! ») (Il convient également de noter que le « contenu ou comportement agressif ou menaçant » n'est pas autorisé sur les pages GitHub, vous ne pourrez donc pas y publier votre version de l'histoire de Hansel et Gretel).

Mon avis

Plus j’examinais la combinaison GitHub Pages + Jekyll (pour cet article), plus je trouvais que l’idée avait une odeur bizarre. L'idée de « créer votre propre site Web avec un minimum d'effort » est géniale. Mais pour travailler dessus, vous avez toujours besoin de la version actuelle sur la machine locale. Et pour quelque chose d'aussi "simple", il y a trop de commandes en ligne de commande. J'ai parcouru les sept pages de la section Mise en route et j'ai eu l'impression que la seule chose simple, c'était moi . Et je n'ai même pas compris la syntaxe simple de la page principale ou les bases d'un simple « mécanisme de création de modèles basé sur le langage Liquid ». Je préfère écrire un site Web moi-même ! Pour être honnête, je suis un peu surpris que Facebook l'utilise pour la documentation React alors qu'ils pourraient probablement créer leurs pages de système d'aide en utilisant React et les pré-afficher sous forme de fichiers HTML statiques chaque jour . Tout ce qu'ils ont à faire est de trouver un moyen de recevoir les fichiers de balisage existants comme s'ils provenaient du CMS. Et si...

#12 Utiliser GitHub comme CMS

Disons que nous avons un site Web avec du texte, mais que nous ne voulons pas stocker ce texte sous forme de balisage HTML. Au lieu de cela, nous aimerions stocker des morceaux de texte quelque part qui peuvent être facilement modifiés par des utilisateurs non-développeurs. De préférence avec une option de versioning. Peut-être même avec une sorte de processus d’examen par les pairs. Voici ce que je suggère : utilisez les fichiers de balisage stockés dans le référentiel pour stocker le texte. Et utilisez un composant côté client qui récupérerait ces morceaux de texte et les afficherait sur la page. Je suis un fan de React, alors voici un exemple d'un composant <Markdown> approprié qui, étant donné un chemin vers un fichier markdown, l'extraira, l'analysera et le restituera au format HTML.

class Markdown extends React.Component {
    constructor(props) {
      super(props);

      // Конечно, вам нужно заменить это на свой URL
      this.baseUrl = 'https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';

      this.state = {
        markdown: '',
      };
    }

    componentDidMount() {
      fetch(`${this.baseUrl}/${this.props.url}`)
        .then(response => response.text())
        .then((markdown) => {
          this.setState({markdown});
        });
    }

    render() {
      return (
        <div dangerouslySetInnerHTML={{__html: marked(this.state.markdown)}} />
      );
    }
}

(J'utilise ici le package marqué npm pour analyser le balisage en HTML) L'URL pointe vers mon exemple de référentiel, qui contient des fichiers de balisage dans le répertoire /text-snippets . (Vous pouvez également utiliser l'API GitHub pour récupérer du contenu , mais je doute que vous en ayez besoin.) Vous pouvez utiliser un composant comme celui-ci :

const Page = () => (
  <div className="page">
    <div className="about-us">
      <Markdown url="about-us.md" />
    </div>

    <div className="disclaimer">
      <p>A very important disclaimer:</p>

      <Markdown url="disclaimers/home-page-disclaimer.md" />
    </div>
  </div>
);

Alors maintenant, GitHub agit, en quelque sorte, comme votre CMS pour les morceaux de texte que vous souhaitez héberger. L'exemple ci-dessus récupère le balisage uniquement après le chargement du composant dans le navigateur. Si vous avez besoin d'un site statique, vous devrez le rendre sur le serveur. Bonnes nouvelles! Rien ne vous empêche de récupérer tous les fichiers de balisage sur le serveur (en utilisant la stratégie de mise en cache de votre choix). Si vous décidez d'emprunter cette voie, il est logique d'utiliser l'API GitHub pour obtenir une liste de tous les fichiers de balisage d'un répertoire. Bonus : utilitaires GitHub ! J'utilise l'extension Octotree Chrome depuis un certain temps maintenant et je vous la recommande. Non sans réserves, mais je le recommande quand même. Il affiche un panneau sur la gauche avec une arborescence du référentiel que vous parcourez. Et grâce à cette vidéo, j'ai découvert octobox , qui me semble également être un très bon utilitaire jusqu'à présent. Il s'agit de la boîte de réception de vos problèmes GitHub. C'est tout ce que vous devez savoir sur lui. En parlant de couleurs, j'ai pris toutes les captures d'écran ci-dessus dans un thème clair pour ne pas vous effrayer. Mais si je préfère les couleurs sombres dans tout le reste, alors pourquoi supporter un GitHub mortellement pâle ? Ici, j'ai utilisé une combinaison de l' extension Stylish pour le navigateur Chrome (qui peut appliquer des thèmes à n'importe quel site Web) et du style GitHub Dark . Et pour commencer, le thème sombre des outils de développement GitHub (intégré, il vous suffit de l'activer) et le thème Atom One Dark pour Chrome.

Bitbucket

À proprement parler, ce n'est pas tout à fait approprié ici, mais je ne peux m'empêcher de mentionner Bitbucket. Il y a deux ans, j'ai démarré un projet et j'ai passé une demi-journée à choisir le meilleur hébergement git. Ainsi, Bitbucket a gagné avec une marge significative. Leur pipeline de révision de code est bien en avance sur la concurrence (c'était bien avant que GitHub n'ait même le concept de réviseur). Depuis, GitHub a également reçu des critiques. Malheureusement, je n'ai pas eu l'occasion d'utiliser Bitbucket l'année dernière - peut-être qu'ils ont encore progressé dans quelque chose. Je recommande donc à ceux qui sont responsables du choix d'un service d'hébergement git de prêter également attention à Bitbucket.

Conclusion

C'est tout! J'espère avoir pu vous dire au moins trois choses qui vous étaient auparavant inconnues. Et j’espère aussi que vous avez passé un bon moment à lire mon article.