Comment débuter avec Github

0
381
Comment débuter avec Github
Comment débuter avec Github

Si vous avez besoin de partager votre code avec d’autres développeurs, Github est fait pour vous. Apprenez comment débuter avec Github.

En effet, il s’agit d’ue plateforme collaborative pour les développeurs. Sa fonctionnalité principale est de permettre d’héberger du code sous Git.
Vous aurez aussi la possibilité d’associer un wiki et une page Web à votre projet, et de faire un suivi des bugs et des versions.
De plus, Github offre de nombreuses fonctionnalités liées aux réseaux sociaux, telles que la possibilité de suivre des projets, des utilisateurs, d’échanger sur les développements.
Pour la suite, nous allons prendre l’exemple d’un nouveau projet, sous Git, dont vous avez la responsabilité d’héberger les sources sur Github pour pouvoir les partager avec vos collègues.

Premiers contacts

Tout d’abord, vous aurez à vous créer un compte sur Github. Une fois identifié, vous avez la possibilité de créer un nouveau dépôt. Pour pouvoir créer ce dépôt, vous devez remplir le nom du dépôt, une description et choisir si le dépôt sera public ou privé. Vous pouvez aussi choisir d’initialiser le dépôt avec un README, un .gitignore, une licence.
Si nous visualisons le dépôt, nous y retrouvons le gitignore initialisé selon le langage choisi, la licence et notre ReadMe qui est initialisé avec le titre du dépôt et sa description.
Et voilà ! Notre projet est initialisé dans github, nous allons pouvoir publier notre code et gérer la configuration du dépôt.

Portage collaboratif

À présent, nous allons pouvoir ajouter des nouveaux participants à notre projet qui auront le droit de modifier les contenus de notre dépôt, d’y ajouter de nouvelles sources, modifier ou supprimer celles existantes. Pour ce faire, nous allons dans la section settings du dépôt, là où il est possible d’ajouter des collaborateurs; ceux-ci doivent avoir un compte sur Github. Notre dépôt étant créé et partagé à nos collègues, nous allons publier du code.
Il existe de nombreuses méthodes de travail avec Git. La plupart prônent la création de branches dédiées pour développer les nouvelles fonctionnalités. Vous pouvez créer ces branches de différentes manières, soit via l’interface de Github, soit via l’application Github téléchargée, soit en ligne de commande.
Nous avons créé une branch dev pour les développements
de nos sprints, nous allons dans les Settings du projet, afin de la définir comme branche par défaut pour nos futures Pull Requests (PR pour les intimes).
Notre dépôt étant créé, configuré et partagé à nos collègues, nous allons pouvoir publier du code. Tout d’abord, il va nous falloir le récupérer en local. Pour cela, nous pouvons faire un clone via ssh / https ou utiliser le bouton “clone in desktop” qui va nous proposer de télécharger l’application Github. Une fois, le dépôt récupéré, nous pouvons l’ouvrir dans notre IDE favori et coder. Nous avons choisi d’effectuer le développement de notre évolution dans une branche locale “story-one”. Nous allons maintenant la publier pour pouvoir créer une PR. Pour cela, il nous suffira d’effectuer un “push” via notre l’outil Git de notre choix (application, ligne de commande,etc.). Automatiquement, Github va nous proposer la possibilité de la comparer avec la branche par défaut et de créer une PR, si la différence nous convient.
Nous choisissons de créer la PR. Github nous propose par défaut de fusionner le code de notre branche story-one avec celui présent sur dev, mais nous pouvons sélectionner une autre branche selon les besoins.
Nous mettons un titre à notre PR ainsi qu’une description dans laquelle nous pouvons utiliser du Markdown. Github nous indique si la PR sera “mergeable”, c’est-à-dire qu’il peut être fusionné sans conflits avec le code existant sur dev.
Une fois, la PR créée, on va pouvoir visualiser plusieurs choses : les différents commits en différence, les modifications dans les fichiers. Une séance partagée de revue de code va pouvoir commencer. Les autres collaborateurs vont pouvoir commenter les commits ou les différences dans les fichiers. Une discussion va pouvoir être menée sur chacun des développements proposés. Suivant les commentaires, nous allons pouvoir reprendre le code proposé et le modifier et ainsi de suite. Une fois que le code est validé, un des membres de l’équipe va pouvoir valider la PR. Github va se charger de “merger” notre branche distante avec la branche de base, ici dev, et nous pouvons à présent visualiser l’ensemble du code de “story-one” sur “dev”.
D’autres informations sont alors modifiées et accessibles au niveau de chaque répertoire et fichier, notamment le dernier commit, qui nous permet de connaître la dernière personne à avoir livré un commit, la date, le titre et le sha1 de ce commit.
Pour pouvoir récupérer votre code, vos collègues n’auront qu’à récupérer en local le contenu du dépôt via un “fetch” ou un “pull”. Ils pourront ainsi proposer leur propre code via de nouvelles PRs. À ne pas oublier le README de votre projet, que vous pourrez modifier à votre guise afin d’apporter une description de votre projet, des cas d’exemple, des illustrations, un tutoriel sur comment utiliser et exécuter votre projet … Et voilà, vous savez tout pour pouvoir vous lancer rapidement dans Github. Mais vous pouvez aller encore plus loin.

Notion de fork

Tout d’abord Github offre la possibilité d’effectuer un “fork” d’un projet. Ce fork va réaliser une copie du projet initial dans un nouveau dépôt. Il conservera un lien vers le projet. L’intérêt ? Pouvoir proposer du code sur des projets où vous n’avez pas les droits en écriture. Ainsi, cette méthode est particulièrement utilisée pour les projets open source et peut être étendue à une gestion plus serrée des droits dans votre dépôt. Par exemple, sur notre projet, Céline et Djo ont les droit pour écrire et valider des PRs, mais si une personne veut contribuer au projet, elle va pouvoir le forker, y apporter les modifications qu’elle souhaite, puis les proposer via une PR; cette dernière ne pourra être validée que par Céline et Djo. Une discussion pourra ainsi commencer entre les acteurs du projet via le système de commentaires que nous avons décrit précédemment.
À présent, si vous voulez gérer les dépôts de votre société, association ou autre structure, vous pourrez créer des “Organisations”, cela va vous permettre de rassembler
tous les dépôts que vous devez gérer au sein d’une même entité et de gérer les droits des participants en les répartissant en “Team”; chaque Team aura des droits qui lui seront propres… Par exemple, vous pouvez avoir une team d’administrateurs qui auront tous les droits sur tous les dépôts, puis une team par dépôt pour les développeurs respectifs des dépôts. En organisant ces développeurs en plusieurs teams, vous pourrez différencier ceux qui auront les droits en écriture et lecture de ceux qui n’auront que les droits en lecture.
À tout cela, nous pouvons ajouter la possibilité de suivre les bugs et les évolutions en cours sur le projet et nous pourrons aussi ajouter un wiki à notre projet qui pourra être complémentaire à notre README pour apporter une documentation plus détaillée de notre projet. Ainsi nous disposons directement d’un bugtracker et d’un wiki qui seront accessibles à l’ensemble des participants de notre projet, ou plus si notre repo est public. Voilà nous avons vu comment créer et administrer notre projet mais Github ne s’arrête pas là. Nous pouvons avoir accès à un certain nombre de statistiques et d’autres outils proposés par la plateforme.

Comme nous avons pu le voir ensemble, Github est une véritable plateforme de communication et d’échange entre les différents participants d’un projet, mais va aussi nous permettre de “follower” d’autres projets.

Évaluez cet article
PARTAGER SUR
Ayoub Belkadi
Ayoub Belkadi est un consultant et Freelance SEO. Il optimise des sites web pour atteindre la première page de Google en utilisant le référencement naturel Whitehat SEO. Il concois aussi des sites web sous la platforme Wordpress 100% responsive.