Introduction github Flashcards
Qu’est-ce que github?
GitHub est une plateforme en ligne de développement collaboratif lancée le 10 avril 2008. Exploitant le logiciel de gestion de versions décentralisé Git, la plateforme permet à tout utilisateur d’y héberger ses projets et de les rendre accessibles au développement coopératif grâce à un système de dépôts, en anglais, repository, retraçant les avancées et modifications apportées aux projets. Outre ses facettes techniques qui attirent les développeurs, l’un des aspects majeurs de GitHub est son caractère social prononcé. Avec plus de 50 millions d’utilisateurs inscrits, le site met l’accent sur les interactions entre ceux-ci en proposant des fonctionnalités de suivi d’utilisateurs, suivi de projets, de discussions et bien d’autres encore, le tout dans une optique de laisser la vaste communauté s’approprier la plateforme.
Quelles sont les limites de github?
Comme toute plateforme gratuite, elle comporte son lot de limitations. En effet, la partie gratuite de GitHub est principalement orientée autour du développement de projets de particuliers. Dès lors qu’une entreprise ou une équipe privée de développeurs cherche à intégrer GitHub à leur mode de fonctionnement, la version gratuite n’est plus suffisante et les organisations sont poussées vers des forfaits payants. Les fonctionnalités ajoutées sont multiples, et peuvent aller d’une simple augmentation de l’espace d’hébergement par utilisateur, à l’ajout de Wikis et de branches protégées. Le détail de ces différents forfaits sont retrouvables ici.
Où se fait la collaboration sur github?
La collaboration sur GitHub s’effectue principalement en termes de dépôts ou repositories en anglais, repo pour faire court. Si l’on souhaite commencer un projet et le partager, on peut créer notre propre dépôt, ou bien participer à un projet en cours sur un dépôt déjà existant. Dans les deux cas, il faut faire le lien entre un dépôt distant hébergé sur GitHub, et un dépôt local hébergé sur votre machine.
Comment fait le lien entre un dépôt distant et un dépôt local?
Via le clone du dépôt distant sur notre machine.
Quelles sont les deux méthodes d’identification pour accéder à github?
Les deux méthodes d’identification pour accéder à GitHub sont https et ssh.
Comment synchronise t-on le dépôt local avec les modifications faites ?
Dans le cadre d’un projet collaboratif, il faut s’attendre à ce que d’autres participants effectuent des modifications et les incorporent au dépôt distant. Dès lors, le dépôt local sur lequel on travaille est voué à se désynchroniser par rapport aux modifications faites par d’autres. Pour récupérer ces changements, on utilisera les commandes git fetch et git pull.
À l’instar de la partie précédente, récupérer des changements effectués sur le dépôt distant se fait en deux étapes :
Vérifier s'il y a eu des changements apportés au dépôt distant à l'aide de la commande git fetch. Celle-ci téléchargera les métadonnées du dépôt sans pour autant télécharger les modifications faites. Elle permet donc de vérifier si des changements peuvent être importés sur le dépôt local. Importer les changements effectués sur le dépôt distant vers le dépôt local à l'aide de la commande git pull.
Quel est la bonne pratique en termes de merge?
Jusqu’à maintenant, les méthodes de travail présentées restent des cas d’école et ne reflètent pas tout à fait le workflow type que l’on peut rencontrer lorsque l’on participe à un projet en coopération sur GitHub. En effet, fusionner une branche de développement vers la branche principale ne se fait pas aussi simplement surtout lorsqu’il s’agit d’un travail sensible aux modifications, les ajouts et changements apportés doivent toujours être revus par un administrateur désigné.
Qu’est-ce qu’une pull request?
Pour encadrer ses fusions de branches, GitHub propose un système de Pull Request (PR). Dans la plupart des cas, une personne de l’organisation sera désignée pour surveiller et autoriser les fusions de branches vers la branche principale du projet. Cet outil a pour but de limiter les merge conflicts ou conflits de modifications, qui peuvent se produire lorsque deux acteurs d’un projet modifient en parallèle sur deux branches différentes, des parties communes du projet. Dans ce genre de situation, les acteurs soumettront une Pull Request à l’administrateur du projet et ce dernier devra se charger d’effectuer les modifications nécessaires pour résoudre les conflits afin d’autoriser le merge des branches.
Qu’est-ce qu’un fork?
Une autre manière de participer à un projet est de fork ce dernier. En résumé, il s’agit de copier l’intégralité d’un dépôt GitHub créé par quelqu’un d’autre et d’en faire un de vos dépôts personnels, le cloner, le modifier… comme si c’était le votre. Ainsi, vous pourrez travailler dessus sans modifier l’architecture propre du dépôt, essayer vos changements de votre côté et une fois que ceux-ci vous conviennent, et que vous pensez qu’ils contribueront au projet originel, vous pouvez soumettre une pull request.
C’est notamment grâce à ce système que les projets open source trouvent des contributeurs : n’importe qui peut forker le dépôt public d’un projet open source, tenter de l’améliorer, et proposer ces modifications via une pull request. Ces changements seront alors examinés par les administrateurs du projet open source, puis acceptés ou refusés. L’administrateur peut également discuter avec le contributeur via la pull request, notamment pour lui demander d’améliorer ses modifications avant qu’il les intègre (mise à jour de la documentation, ajout de test, de commentaires, etc.).
Qu’est-ce qu’une issue?
Vous pouvez également créer des “issues” (problèmes) sur un de vos dépôt, ou un dépôt public d’un projet open source. Une issue peut servir à faire remonter un bug, demander l’ajout d’une fonctionnalité, ou simplement poser une question quant au projet.
Qu’est-ce qu’un workflow?
Mais pour bien utiliser un système de gestion de versions, en connaître les commandes ne suffit pas. Il faudra également définir des process et les respecter.
Git en particulier est un outil très complet permettant de très nombreuses opérations, certaines d’entre elles étant plus ou moins équivalentes. Si chaque membre de l’organisation utilise les outils différemment, sans suivre un process commun à l’ensemble de l’équipe de développement, il en résultera de très nombreux conflits. Ceux-ci peuvent être résolus, mais c’est en général une opération chronophage, et il vaut donc mieux éviter les conflits que les résoudre.
C’est pourquoi des process standardisés (workflows) ont été définis. quant à l’utilisation de Git. Il en existe plusieurs, et l’adoption d’un workflow plutôt qu’un autre sera en général la responsabilité du technical leader de l’équipe de développement. Les membres de l’équipe doivent cependant connaître et comprendre les différents workflows, et respecter le workflow choisi.
Qu’elles sont les deux workflow les plus connus?
Git flow et github flow.
Décrire le git flow
Git Flow repose sur un branching model (modèle de branche) relativement complexe. Il comporte les branches suivantes :
main (ou master) : C'est la branche stable, dont les différents commits reflètent les versions du code qui ont été déployées en production. Pour chaque commit de cette branche, on crée en général un tag qui porte le nom de la version (par exemple 1.0.1) develop : C'est la branche de développement, à partir de laquelle les développeurs vont créer les feature branches feature branches : ce sont les branches créées à partir de develop pour travailler sur une nouvelle fonctionnalité (feature). Par exemple, si vous êtes chargé d'implémenter l'authentification sur votre application, vous devrez créer une branche feature/auth à partir de develop. Une fois l'authentification implémentée, vous fusionnerez vos changement dans la branche develop (via une pull request). release branches : Une fois que les features que l'on souhaite déployer dans la prochaine release (sortie de la prochaine version de l'application) ont été développées et fusionnées dans develop, on peut créer une branche de release à partir de develop, dont le nom contient en général le numéro de la version (par exemple release/1.0.1). Ce code sera ensuite testé extensivement, et on pourra effectuer quelques corrections de bugs (bug fix) si nécessaire. Par la suite, on fusionnera la branche de release à la fois dans la branche main / master et dans la branche develop, et on pourra déployer la nouvelle version en production. hotfixes : ces branches sont créées à partir de main / master afin de corriger les bugs importants en production. Ces branches sont par la suite fusionnées à la fois dans la branche main / master et dans la branche develop.
Décrire le github flow
Comme nous l’avons vu, Git Flow est un workflow avec un branching model relativement complexe. Si ce modèle a des avantages, il peut néanmoins s’avérer lourd dans certains cas, notamment lorsque les releases sont très fréquentes (par exemple hebdomadaire voire quotidienne).
Certains workflows ont été défini dans le but de proposer un modèle plus simple et plus adapté dans le cas où l’on souhaite déployer les modifications dès qu’elles ont été développées, sans les regrouper au sein d’une release. C’est notamment le cas de GitHub Flow.
Le branching model est donc beaucoup plus simple : il comporte une branche main (ou master) qui contient les versions “déployables” de l’application. A partir de cette branche, les développeurs créeront de nouvelles branches pour travailler sur des features ou des bug fix. Après avoir implémenté la nouvelle feature ou corrigé le bug, la branche sera directement “mergée” dans main / master via une Pull Request
