Collaboration en équipe avec GitHub

GitHub est devenu la pierre angulaire de tout ce qui concerne les logiciels open source. Les développeurs l'adorent, y collaborent et construisent en permanence des projets impressionnants. En plus d'héberger notre code, GitHub l'utilise principalement comme outil collaboratif. Dans ce didacticiel, explorons certaines des fonctionnalités les plus utiles de GitHub, en particulier pour le travail en équipe, en le rendant encore plus efficace, productif et surtout amusant.!

Collaboration entre Github et Logiciels

Une chose que je trouve très utile est d'intégrer le wiki Github dans le projet principal de code source..

Ce tutoriel suppose que vous connaissez déjà Git, le système de contrôle de version distribué open source, créé par Linus Torvalds en 2005. Si vous avez besoin d'une révision ou d'une recherche sur Git, consultez notre précédent cours de screencast ou même certains messages. En outre, vous devriez déjà avoir un compte Github et exécuter certaines fonctions de base, telles que créer un référentiel et transmettre les modifications à Github. Si ce n'est pas le cas, rendez-vous sur d'autres didacticiels précédents sur ce sujet..

Dans le monde des projets logiciels, il est inévitable que nous travaillions en équipe pour réaliser un projet. Pour ce tutoriel sur Github et la collaboration d’équipes, nous allons explorer quelques-uns des outils les plus courants dont nous avons généralement besoin lorsque nous travaillons avec des équipes logicielles. Les outils discutés sont:

Ajout de membres de l'équipe - Organisation et collaborateurs
Demandes de traction - Envoi et fusion
Suivi des bogues - Problèmes Github
Analytique - Graphes & Réseau
Gestion de projet - Trello & Pivotal Tracker
Intégration continue - Travis CI
Examen du code - Commentaire de ligne et requêtes URL
La documentation - Wiki & Hubot

Préférer un screencast?

Si vous préférez un screencast pour une visite visuelle, sautez juste en dessous pour le visionner et référez-vous à ce tutoriel en tant que notes complémentaires:

Télécharger la video

Outil 1: Ajout de membres de l'équipe

Il existe généralement deux façons de configurer Github pour une collaboration en équipe:

Les organisations - Le propriétaire de l'organisation peut créer plusieurs équipes avec différents niveaux d'autorisation pour différents référentiels.
Collaborateurs - Le propriétaire du référentiel peut ajouter des collaborateurs avec un accès en lecture et en écriture pour un référentiel unique.

Les organisations

Si vous supervisez plusieurs équipes et souhaitez définir différents niveaux de permission pour chaque équipe avec différents membres et ajouter chaque membre à différents référentiels, l'organisation sera la meilleure option. N'importe quel compte d'utilisateur Github peut déjà créer des organisations libres pour les référentiels de code source ouvert. Pour créer une organisation, accédez simplement à la page des paramètres de votre organisation:

Pour accéder à la page des équipes de votre organisation, vous pouvez simplement aller à http://github.com/organizations/[organization-name]/teams pour les voir ou même visiter https://github.com/organizations/[organization-name]/teams/new pour créer de nouvelles équipes avec des membres de 3 niveaux d'autorisation différents, tels que:

Tirer seulement: Récupérer et fusionner avec un autre référentiel ou une copie locale. Accès en lecture seule.
Pousser et tirer: (1) avec mise à jour du repo distant. Accès en lecture + écriture.
Push, Pull & Administrative: (1), (2) ainsi que des droits sur les informations de facturation, la création d’équipes et la suppression de comptes d’organisation. Lecture + écriture + accès administrateur

Collaborateurs

Les collaborateurs sont habitués à donner les deux Accès en lecture + écriture vers un référentiel unique appartenant à un compte personnel. Pour ajouter des collaborateurs (autres comptes personnels Github), allez simplement à https://github.com/[nomdirecteur/derepo-nomere/settings/collaboration:

Une fois que cela est fait, chaque collaborateur verra une modification du statut d'accès sur la page du référentiel. Après avoir accès en écriture au référentiel, nous pouvons effectuer une Git Clone, travailler sur les changements, faire un git pull pour récupérer et fusionner les modifications éventuelles dans le référentiel distant et finalement git push, mettre à jour le référentiel distant avec nos propres modifications:

Outil 2: demandes de tirage

Les demandes d'extraction sont un moyen formidable de contribuer à un référentiel de manière indépendante en le forçant. À la fin de la journée, si nous le souhaitons, nous pouvons envoyer une demande d'extraction au propriétaire du référentiel afin de fusionner les modifications de code. La demande d'extraction en elle-même peut alors déclencher des discussions sur la qualité du code, les fonctionnalités ou même la stratégie générale..

Passons maintenant aux étapes de base pour une demande d'extraction.

Lancer une demande de tirage

Il existe deux modèles de demande de tirage dans Github:

Modèle de fourche et traction - Utilisé dans un référentiel public pour lequel nous n'avons pas d'accès Push
Partager le modèle de référentiel - Utilisé dans un référentiel privé pour lequel nous avons un accès push. La fourche n'est pas obligatoire dans ce cas.

Nous voyons ici le flux de travail entre deux utilisateurs (propriétaire du repo et forked-repo-owner) pour le modèle Fork and Pull:

Identifiez le référentiel Github auquel vous souhaitez contribuer, puis cliquez sur le bouton "Fourche" pour créer un clone du référentiel dans votre propre compte Github:
Cela créera une copie exacte du référentiel dans votre propre compte.
Choisissez l’URL SSH pour qu’il vous demande votre phrase secrète de clé SSH au lieu du nom d’utilisateur et du mot de passe chaque fois que vous le souhaitez. git push ou git pull. Ensuite, nous allons cloner ce dépôt sur notre machine locale:
```
 $ git clone [ssh-url] [nom du dossier] $ cd [nom du dossier]
```
Généralement, nous allons créer une nouvelle branche git pour chaque nouvelle fonctionnalité. C'est une bonne pratique car à l'avenir, si nous mettons à jour la branche après quelques discussions, la demande d'extraction sera automatiquement mise à jour. Créons une nouvelle branche pour effectuer un changement très simple afin de modifier le readme.md fichier:
```
 $ git checkout -b [nouvelle fonctionnalité]
```
Après avoir effectué les ajouts nécessaires à la création des nouvelles fonctionnalités, nous ne ferons que valider les nouvelles modifications et effectuer le paiement dans la branche git master:
```
 $ git add. $ git commit -m "informations ajoutées au fichier readme" $ git checkout master
```
À ce stade, nous allons pousser la branche vers le référentiel distant. Pour cela, nous allons d’abord vérifier le nom de la branche avec la nouvelle fonctionnalité, ainsi que les alias de référentiel distant git. Ensuite, nous allons pousser les changements en utilisant git push [git-remote-alias] [nom de la branche]:
```
 $ git branche * maître readme $ git à distance -v origine [email protected]: [forked-repo-propriétaire-nom_utilisateur] / [nom-repo] .git (fetch) origine [email protected]: [forked-repo- propriétaire-nom d'utilisateur] / [nom-repo] .git (push) $ git push origine readme
```
Dans notre page Github de référentiel créé, nous allons passer à la branche avec la nouvelle fonctionnalité, puis cliquer sur le bouton "Demander une requête".
Une fois la demande d'extraction soumise, elle nous amène directement à la page de demande d'extraction du référentiel d'origine. Nous verrons notre demande de tirage à la fois comme une nouvelle question et une nouvelle demande de tirage..
Après la discussion, il est possible que le propriétaire du référentiel créé souhaite modifier la nouvelle fonctionnalité. Dans ce cas, nous allons passer à la même branche de notre machine locale, la valider et la renvoyer à Github. Lorsque nous visiterons la page de demande d'extraction du référentiel d'origine, celle-ci sera automatiquement mise à jour.!

Fusion d'une demande de tirage

Si vous êtes le propriétaire du référentiel d'origine, il existe deux façons de fusionner une demande d'extraction entrante:

Fusionner directement sur Github: Si nous fusionnons directement dans Github, assurez-vous qu'il n'y a pas de conflit et qu'il est prêt à être fusionné dans la branche principale. Le propriétaire du référentiel d'origine peut simplement cliquer sur le bouton vert "Fusionner la requête d'extraction" pour le faire:
Fusionner dans nos machines locales: D'autres fois, il peut y avoir des conflits de fusion, et en cliquant sur le bouton "info", Github aura des instructions claires sur la façon de fusionner la branche de notre machine locale en enregistrant les modifications depuis la branche du contributeur:

Il existe différents modèles de branches utilisés pour la gestion des versions dans les équipes de développement logiciel. Voici deux modèles de flux de travail git populaires: (1) le flux de travail Github qui a un modèle de branche simple et utilise des demandes d'extraction et (2) Gitflow qui a une branche plus étendue. Le modèle finalement choisi variera certainement en fonction de l'équipe, du projet et de la situation..

Outil 3: Suivi des bogues

Les demandes d'extraction sont un moyen formidable de contribuer à un référentiel de manière indépendante en le forçant..

Dans Github, le centre de tous les suivis de bogues sont les problèmes. Même s'ils sont principalement destinés au suivi des bogues, il est également utile d'utiliser Problèmes de l'une des manières suivantes:

Bogues: Les choses qui sont évidemment cassées et ont besoin de corrections
Caractéristiques: Super nouvelles idées géniales à mettre en œuvre
Liste de choses à faire: Une liste de contrôle des éléments à compléter

Explorons certaines des fonctionnalités des problèmes:

Étiquettes: Ce sont des catégories colorées pour chaque numéro. Ils sont utiles pour filtrer les problèmes en conséquence.
Jalons: Ce sont des catégories datées qui peuvent être associées à chaque problème et qui sont utiles pour identifier les problèmes sur lesquels il faut travailler dans la prochaine version. De plus, étant donné que les jalons sont liés aux problèmes, il met automatiquement à jour la barre de progression à la fermeture de chaque problème associé..
Chercher: Recherche automatique pour les problèmes et les jalons

Affectation: Chaque problème peut être attribué à un responsable pour le résoudre. C’est une autre fonctionnalité utile pour voir sur quoi nous devrions travailler..

Fermeture automatique: Commit des messages avec Corrections / Corrigé ou Fermeture / Fermeture / Fermé # [numéro d'émission] fermera automatiquement le problème.
```
 $ git add. $ git commit -m "URL corrigée corrige # 2" $ git push origin master
```
Mentions: Tout le monde peut aussi laisser une note en indiquant simplement #[numéro de série] dans leurs messages. Étant donné que les numéros de problème sont liés par un lien hypertexte, il est très facile de mentionner des problèmes connexes au cours de la discussion..

Outil 4: analyse

Il est clair que nous pouvons associer étroitement notre liste de tâches et les mises à jour de nos commits de code..

Deux outils permettent de mieux comprendre un référentiel: Graphes et Réseau. Github Graphs fournit un aperçu des collaborateurs et des validations derrière chaque référentiel de code, tandis que Github Network fournit une visualisation de chaque contributeur et de leurs validations dans tous les référentiels forkés. Ces analyses et graphiques deviennent très puissants, surtout lorsque vous travaillez en équipe.

Graphiques

Les graphiques fournissent des analyses détaillées telles que:

Contributeurs: Qui étaient les contributeurs? Et combien de lignes de code ont-ils ajouté ou supprimé?
Activité de validation: Quelles semaines les commits ont-ils eu lieu l'année dernière??
Fréquence de code: Combien de lignes de code ont été engagées tout au long du cycle de vie du projet?
Carte perforée: Pendant quels moments de la journée les commits ont généralement lieu?

Réseau

Github Network est un outil puissant qui vous permet de voir les commits de chaque contributeur et leur relation les uns avec les autres. Lorsque nous examinons le visualiseur dans son intégralité, nous voyons chaque commit sur chaque branche de chaque référentiel appartenant à un réseau. Perspicace!

Outil 5: Gestion de projet

Bien que Github Issues dispose de fonctionnalités de gestion de projet avec problèmes et jalons, certaines équipes peuvent préférer un autre outil en raison d'autres fonctionnalités ou du flux de travail existant. Dans cette section, nous verrons comment nous pouvons relier Github à deux autres outils de gestion de projet populaires - Trello et Pivotal Tracker. Avec les points d'ancrage de service Github, nous pouvons automatiser la tâche de mise à jour avec des validations, des problèmes et de nombreuses autres activités. Cette automatisation permet non seulement de gagner du temps, mais augmente également la précision des mises à jour pour toutes les équipes de développement logiciel..

Github et Trello

Trello fournit un moyen simple et visuel de gérer des tâches. À l'aide des méthodologies de développement logiciel agile, les cartes Trello peuvent émuler un simple tableau Kanban virtuel. Par exemple, nous créerons automatiquement une carte Trello chaque fois qu'une demande d'extraction est faite à l'aide de points de service Github. Passons les marches!

Ouvrez un compte dans Trello si vous n'en avez pas déjà et créez un nouveau tableau Trello..
Allez dans le référentiel Github> Paramètres> Crochets de service> Trello
Obtenir le JETON sous Notes d'installation n ° 1 avec le lien hypertexte fourni pour l'authentification.
Sous Notes d’installation n ° 2, utilisez l’URL indiquée pour générer une structure au format json qui nous donne la identifiant de liste pour chaque carte Trello. BOARDID fait partie de l'URL lorsque nous visitons le conseil à https://trello.com/board/[BOARD-NAME]/[BOARDID]. JETON peut être créé avec le lien hypertexte donné sous Notes d'installation n ° 1.
Retour dans les crochets de service Github, mettez dans le identifiant de liste et le jeton. Vérifiez Actif, Testez le crochet et nous sommes tous prêts à obtenir des mises à jour automatiques chaque fois qu'il y a une demande d'extraction..
La prochaine fois qu'il y aura une demande de tir, la carte Pull Request Trello aura automatiquement un nouvel élément.!

Github et Pivotal Tracker

Pivotal Tracker est un autre outil de gestion de projet léger et agile dans lequel la planification basée sur des histoires permet à l’équipe de collaborer facilement en réagissant instantanément aux divers changements et progrès du projet. Sur la base des progrès actuels de l'équipe, il peut également créer des graphiques pour analyser sa vitesse, son utilisation, son utilisation, son utilisation, etc. Dans ce court exemple, nous allons automatiquement livrer une histoire en la reliant à un commit Github.!

Créer un nouveau projet dans Pivotal Tracker avec une nouvelle histoire à livrer.
Allez dans Profil> Jeton d'API (juste en bas). Copier le jeton d'API donné.
Revenez dans le référentiel Github> Paramètres> Crochets de service> Suivi des pivots. Collez le jeton, cochez Actif et cliquez sur Paramètres de mise à jour. Nous sommes tous prêts à fournir automatiquement des récits de suivi de pivot avec des commits de Github.!
Enfin, nous allons valider nos modifications et ajouter l'identifiant du tracker au message de validation au format git commit -m "message [livre #tracker_id]"
```
 $ git add. $ git commit -m "Implémentation des crochets Github et Pivotal Tracker [livre # 43903595]" $ git push
```
Maintenant, quand nous reviendrons sur le Pivotal Tracker, nous verrons que l’histoire a été automatiquement livrée avec des liens vers le commit exact de Github qui montre les modifications apportées au fichier.!

Avec ces exemples Trello et Pivotal Tracker, il est clair que nous pouvons associer étroitement notre liste de tâches et les mises à jour de nos commits de code. C'est un gain de temps considérable lorsque vous travaillez en équipe et une précision accrue lorsque vous liez des tâches à des validations exactes. La bonne nouvelle est que, si vous utilisez déjà d'autres outils de gestion de projet tels qu'Asana, Basecamp et d'autres, vous pouvez également créer des points d'ancrage de service de manière similaire. S'il n'y a pas de points de service pour votre outil de gestion de projet actuel, vous pouvez même en créer un.!

Outil 6: Intégration continue

L’intégration continue (CI) est une partie importante de tous les projets de développement logiciel qui travaillent avec des équipes. CI s'assure que, lorsqu'un développeur contrôle son code, une construction automatisée (y compris des tests) détecte les erreurs d'intégration le plus rapidement possible. Cela réduit nettement les erreurs d'intégration et rend l'itération rapide beaucoup plus efficace. Dans cet exemple, nous verrons comment Travis CI peut être utilisé avec Github for CI pour détecter les erreurs et recommander une fusion lorsqu'il passe tous les tests..

Configuration de Travis CI

Nous allons utiliser un simple projet "hello-world" pour node.js avec grunt.js en tant qu'outil de construction pour configurer un projet Travis CI. Voici les fichiers du projet:

le bonjour.js fichier est le projet de noeud. Ici, nous allons délibérément laisser un point-virgule pour ne pas laisser passer l'outil de construction Grunt pour le peluchage:

 var http = require ('http'); http.createServer (fonction (req, res) res.writeHead (200, 'Content-Type': 'text / plain')); res.end ('Hello World in Node! \ n') // sans point-virgule , cela ne lâchera pas). listen (1337, '127.0.0.1'); console.log ('Serveur fonctionnant à http://127.0.0.1:1337/');

package.json dénote les dépendances:

 "name": "hello-team", "description": "Une démo pour github et travis ci pour une collaboration d'équipe", "author": "name "," version ":" 0.0.1 "," devDependencies ": " grunt ":" ~ 0.3.17 "," scripts ": " test ":" grunt travis --verbose "

le gruntjs L’outil de construction n’a qu’une tâche (linteuse) pour plus de simplicité:

 module.exports = fonction (grunt) grunt.initConfig (lint: fichiers: ['hello.js']); grunt.registerTask ('default', 'lint'); grunt.registerTask ('travis', 'lint'); ;

.travis.yml est un fichier de configuration Travis qui obligera Travis à exécuter nos tests:
```
 language: node_js node_js: - 0.8
```
Ensuite, connectez-vous à Travis avec votre compte Github et activez le raccordement au référentiel sous l'onglet Référentiel..
Si l'étape précédente ne déclenche pas la construction, nous devrons alors configurer manuellement le hook de service. Pour le configurer manuellement, copiez le jeton sous l'onglet du profil..
Retournez dans le référentiel Github pour configurer les points d'ancrage du service Github Travis avec le jeton..
Pour la première fois, nous devons faire un manuel git push pour déclencher la première construction de Travis et si tout va bien, il suffit de visiter http://travis-ci.org/[nomdirecteur/[repo-name] pour voir le statut de construction en train de passer!

Travis CI avec demandes de traction

Auparavant, sans aucun élément de configuration dans le processus de demande d'extraction, les étapes suivaient un processus semblable à celui-ci (1) test de demande d'extraction envoyé (2) merge (3) pour voir s'il réussissait / échouait. Avec Travis CI connecté aux demandes d'extraction, nous pourrons inverser les étapes 2 et 3, ce qui augmentera encore la prise de décision rapide quant à l'opportunité de fusionner avec Travis et de nous donner le statut à chaque demande d'extraction. Voyons comment y arriver.

Envoyez une demande de transfert avec une construction en cours de route et Travis mettra tout en œuvre pour vous faire savoir qu'il est bon de fusionner avant même de fusionner.
Si la demande d'extraction échoue à la construction, Travis vous alertera également.
Si nous cliquons sur le bouton d’alerte rouge, il sera également relié à la page travis pour nous montrer les détails de la construction..

Travis CI avec Github est extrêmement utile pour les équipes en raison de la génération automatisée et de la notification immédiate. Cela raccourcit certainement le cycle de correction d'erreur. Si vous utilisez Jenkins, un autre outil de CI populaire, vous pouvez également configurer les hooks de service Github de la même manière..

Outil 7: Révision du code

Avec chaque commit, Github permet une interface propre pour les commentaires généraux ou même des commentaires spécifiques sur une ligne de code. La possibilité de formuler des commentaires ou des questions sur chaque ligne de code est très utile pour effectuer des révisions de code ligne par ligne. Pour afficher les commentaires en ligne, cochez la case située en haut de chaque commit..

Examinons quelques modèles d'URL qui peuvent être utilisés pour nous aider dans la révision de code en nous donnant rapidement les différences entre les validations:

Comparer les branches / tags / SHA1 : utiliser le modèle d'URL https://github.com/[nomdirecteur//repo-nomere/compare/[starting-SHA1]… [ending-SHA1]. Vous pouvez faire la même chose avec des branches ou des tags.
Comparer sans espaces : ajouter ?w = 1 aux urls de comparaison
Diff : ajouter .diff aux URL de comparaison pour obtenir le git diff informations en texte brut. Cela pourrait être utile à des fins de script.
Pièce : ajouter .pièce aux URL de comparaison pour obtenir le git diff informations formatées pour l'envoi de correctifs par courrier électronique.
Liaison de ligne : Lorsque nous cliquons sur le numéro de ligne d’un fichier, Github ajoute un #ligne à la fin de l'URL et rendre la couleur d'arrière-plan de la ligne entière en jaune. C'est chouette pour indiquer la ligne exacte. Il accepte également les gammes de lignes en ajoutant #début Fin. Voici des exemples de liaison de ligne et de liaison de plage.

Outil 8: documentation

Dans cette section, nous allons explorer deux méthodes de documentation:

Documentation formelle: Github Wiki pour créer de la documentation pour le code source
Documentation informelle: Github Hubot pour documenter les discussions entre les membres de l'équipe et automatiser la récupération d'informations en interagissant avec un robot de chat amusant!
Mentions, raccourcis et Emoji

Github Wiki

Un wiki Github peut être créé avec chaque référentiel, ce qui peut s'avérer extrêmement pratique pour placer le code source et la documentation dans le même référentiel. Pour créer le wiki, il suffit d'accéder à l'onglet Wiki de l'en-tête principal et vous êtes prêt à créer des pages avec des informations. Le wiki lui-même a son propre versioning, et les données peuvent être clonées sur notre machine locale pour des mises à jour ou même un accès hors ligne..

Une chose que je trouve très utile est d'intégrer le Wiki Github dans le projet de code source principal afin de ne pas avoir à gérer deux projets Git distincts. Pour ce faire, j'ajoute le dépôt Wiki git en tant que sous-module de la branche master. Si vous utilisez Travis CI ou tout autre CI, assurez-vous que l'outil de construction ignore le sous-module wiki. Pour le fichier Travis CI .travis.yml, ajoutez ce qui suit:

 git: sous-modules: faux

Ajoutez ensuite un wiki de sous-module git au référentiel de code principal:

 $ git submodule add [email protected]: [nom d'utilisateur] / [nom-repo] .wiki.git Clonage dans 'hello-team.wiki'… remote: Comptage d'objets: 6, terminé. remote: Compression d'objets: 100% (3/3), c'est fait. remote: Total 6 (delta 0), réutilisé 0 (delta 0) Réception d'objets: 100% (6/6), terminé. $ git add. $ git commit -m "a ajouté le wiki en tant que sous-module" $ git push origin master

Maintenant, le wiki apparaîtra proprement comme un sous-module dans le projet de code source principal.

Github Hubot

Hubot, en bref, peut apporter énormément de plaisir en documentant et en informant les discussions d'équipe sur les commits importants.

Hubot est simplement un robot de discussion qui peut récupérer des informations ou fournir une notification lorsqu'il est connecté à des commits, des problèmes ou des activités Github. Dans une équipe qui cherche à réduire considérablement les réunions, voire à les éliminer totalement, Hubot avec une interface de discussion entre les membres de l’équipe permet de documenter chaque discussion. Cela favorise certainement les horaires de travail flexibles, car personne ne doit être présent en même temps pour que des discussions puissent avoir lieu. Attention: Hubot est terriblement addictif!

Commençons par configurer Hubot sur Heroku et, en tant que bot, avec l'interface de discussion Campfire! Pour Heroku et Campfire, il existe des versions gratuites pour commencer.

Nous allons utiliser la version Campfire de Hubith de Github. Si vous le souhaitez, vous pouvez consulter les adaptateurs pour d’autres chats tels que Skype, IRC, Gtalk, etc..
Ouvrez un nouveau compte Campfire juste pour Hubot et ce compte créera un nouveau forum de discussion auquel tous les autres utilisateurs seront invités plus tard..
Déployez Hubot sur Heroku en suivant les instructions données dans le wiki de Hubot. Ne vous inquiétez pas si l’URL de l’application heroku vous donne Ne peut pas obtenir / comme il n'y a rien à obtenir par défaut.
Sur le compte Hubot Campfire, invitez-vous. Maintenant, connectez-vous à votre propre compte Campfire et exécutez Aide de Hubot. Il vous donnera toutes les commandes disponibles pour hubot.
Essayez, par exemple hubot l'expédier ou hubot map me CERN.
Ensuite, nous ajouterons un script Hubot. Il y en a beaucoup avec des illustrations de commande.
À titre d'exemple, nous allons ajouter le script github-commits afin que, chaque fois qu'il y a une validation, Hubot nous en informe dans la salle de discussion. Mettre le fichier github-commits.coffee à l'intérieur de des scripts dossier.
Mettre à jour package.json fichier avec les dépendances appropriées comme indiqué sur chaque fichier de script hubot sous commentaires.
Déployez à nouveau les modifications apportées à Heroku avec git push maître heroku.
Accédez au référentiel dans le Github dont la notification de validation sera affichée dans le chat. Ajoutez le hook Web sous les paramètres du repo. Dans le cas du script dit "github-commit", le Webhook sera [HUBOT_URL]: [PORT] / hubot / gh-commits? Room = [ROOM_ID]
La prochaine fois que le référentiel aura un commit, le Hubot discutera et le dira.!

Consultez d'autres scripts Hubot liés à Github, ou si vous voulez en écrire un, il existe également un didacticiel intéressant à ce sujet! Hubot, en bref, peut apporter énormément de plaisir en documentant et en informant les discussions de l'équipe sur les commits, problèmes et activités importants ayant lieu avec nos référentiels Github. Essaie!

Pour conclure sur l’utilisation de l’équipe sur Github, voici quelques conseils de productivité:

Mentions - Dans n'importe quelle zone de texte, nous pouvons mentionner un autre utilisateur de github avec @utilisateur et l'utilisateur sera averti du

Code