You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Voici tous les termes techniques de git que vous finirez par utiliser naturellement. Pas la peine de lire toute cette partie d'une traite,vous pouvez y revenir quand vous bloquez sur un mot.
Git
Git est un protocole, autrement dit une norme de fonctionnement à laquelle la plupart des logiciels voulant gérer du code se plient. Cette norme est pensée pour gérer des projet de code ... mais pas que ! On va y revenir. Il en existent d'autres tels que SVM, mais on s'en fout, git > all.
Github
Tout comme Gitlab et bien d'autres, Github n'est qu'un site qui héberge du code et implémente le protocole git. Il propose également quelques outils additionnel de gestion de projet comme des issues, ce forum de discussion etc. (parfois difficile de savoir ce qui est git et ce qui ne l'est pas, mais c'est suffisamment bien fait pour qu'on ai pas besoin de se poser la question !)
Répertoire git (ou "repo" pour les intimes)
(Repository en anglais) Il s'agit simplement du nom donné à votre projet une fois qu'il utilise git, tout simplement ! Cette distinction est importante car là où en temps normal, si vous supprimez votre projet, vous le perdez complètement, ici le projet sera a plusieurs endroits, dont un endroit qui servira de projet "maitre" (celui sur lequel les autres vont se base pour se mettre à jour, qu'on appel "origin"). Cet endroit, c'est généralement Github/Gitlab/autre de sorte à ce que tout le monde puisse y avoir accès tout en étant sûr que le projet risque pas d'être perdu parce que vous avez renversé du café sur votre ordinateur.
Cloner un répo
Consiste à créer une copie locale (sur votre ordinateur) du projet lié à celui qui est hébergé sur Github (le fameux emplacement qu'on appel "origin").
Pull
Récupère toutes les modifications apporté sur origin et les applique en local (en gros, ça synchronise Github -> votre ordi). Contrairement à copier/coller un dossier sur un autre, cette opération n'écrase pas tout votre projet local, elle ne fait qu'appliquer les modifications qu'origin a subit depuis votre dernier pull ! Autrement dit, si vous éditez le fichier A et que quelqu'un fait une modif sur le fichier B qu'il envoi sur Github, lorsque vous allez pull, seul le fichier B va être modifié. Si vous avez tous les deux modifié le même fichier mais sur des lignes éloignées, git est également capable de faire la distinction ! Par contre, si vous modifiez les mêmes lignes, il y aura un conflit qu'il faudra résoudre, mais pour le moment, on ne s'en préoccupe pas.
Commit
Git permet de faire du versionnage, c'est à dire que vous aurez la possibilité de retracer tout l'historique de l'évolution du projet et potentiellement revenir a une version précédente. C'est très pratique lorsque vous vous adonnez à un système complexe et que vous rencontrez un problème de design qui nécessite de refaire une partie de ce que vous avez fait. Plutôt que d'essayer de retrouver chaque modification que vous avez apporter pour la défaire (et généralement en oublier plein), vous pourrez simplement revenir a un commit précédent, où le soucis de design n'a pas encore été introduit. A chaque lot de modification de votre projet, une fois que vous en êtes satisfait, vous ferez alors un commit, qui est une sorte de sauvegarde de ces modifications et qui, cumulée à TOUS les commits (= lots de modification) précédents, permet à git de reconstruire l'état exacte du code au moment où le commit est fait (c'est foutrement bien fait !). Un commit se fait en local, sur votre ordinateur donc, et vous devrez ensuite envoyer vos commits à Github via un "push"
Push
L'opération inverse du pull. Ici, vous envoyer à Github vos modifications (synchronisation local -> origin). De la même façon, ça ne modifiera sur Github que ce que vous avez modifié, rien d'autre, ce qui permet à d'autres utilisateurs d'appliquer des modifications en parallèle ! Même si on y reviendra en détail, vous l'aurez compris rien qu'à ces définitions, l'idée est de d'abord pull pour se mettre à jour localement, puis modifier son code, commit à chaque fois qu'on fait une avancée satisfaisante, puis push une fois la fonctionnalité implémenté !
Premiers pas
Ici on va apprendre à utiliser Git au travers des outils suivants :
Github pour l'hébergement de code
Github Desktop pour synchroniser votre projet sur votre ordinateur avec celui sur Github
Visual Studio Code pour développer (ce dernier propose également de faire office de Github Desktop, mais c'est bien moins intuitif).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Pratiquement tout le monde connait git mais, à part pour ceux qui l'utilisent déjà, c'est un outil assez mystérieux. C'est parti pour démystifier ça !
Sommaire
Vocabulaire
Voici tous les termes techniques de git que vous finirez par utiliser naturellement. Pas la peine de lire toute cette partie d'une traite,vous pouvez y revenir quand vous bloquez sur un mot.
Git
Git est un protocole, autrement dit une norme de fonctionnement à laquelle la plupart des logiciels voulant gérer du code se plient. Cette norme est pensée pour gérer des projet de code ... mais pas que ! On va y revenir. Il en existent d'autres tels que SVM, mais on s'en fout, git > all.
Github
Tout comme Gitlab et bien d'autres, Github n'est qu'un site qui héberge du code et implémente le protocole git. Il propose également quelques outils additionnel de gestion de projet comme des issues, ce forum de discussion etc. (parfois difficile de savoir ce qui est git et ce qui ne l'est pas, mais c'est suffisamment bien fait pour qu'on ai pas besoin de se poser la question !)
Répertoire git (ou "repo" pour les intimes)
(Repository en anglais) Il s'agit simplement du nom donné à votre projet une fois qu'il utilise git, tout simplement ! Cette distinction est importante car là où en temps normal, si vous supprimez votre projet, vous le perdez complètement, ici le projet sera a plusieurs endroits, dont un endroit qui servira de projet "maitre" (celui sur lequel les autres vont se base pour se mettre à jour, qu'on appel "origin"). Cet endroit, c'est généralement Github/Gitlab/autre de sorte à ce que tout le monde puisse y avoir accès tout en étant sûr que le projet risque pas d'être perdu parce que vous avez renversé du café sur votre ordinateur.
Cloner un répo
Consiste à créer une copie locale (sur votre ordinateur) du projet lié à celui qui est hébergé sur Github (le fameux emplacement qu'on appel "origin").
Pull
Récupère toutes les modifications apporté sur origin et les applique en local (en gros, ça synchronise Github -> votre ordi). Contrairement à copier/coller un dossier sur un autre, cette opération n'écrase pas tout votre projet local, elle ne fait qu'appliquer les modifications qu'origin a subit depuis votre dernier pull ! Autrement dit, si vous éditez le fichier A et que quelqu'un fait une modif sur le fichier B qu'il envoi sur Github, lorsque vous allez pull, seul le fichier B va être modifié. Si vous avez tous les deux modifié le même fichier mais sur des lignes éloignées, git est également capable de faire la distinction ! Par contre, si vous modifiez les mêmes lignes, il y aura un conflit qu'il faudra résoudre, mais pour le moment, on ne s'en préoccupe pas.
Commit
Git permet de faire du versionnage, c'est à dire que vous aurez la possibilité de retracer tout l'historique de l'évolution du projet et potentiellement revenir a une version précédente. C'est très pratique lorsque vous vous adonnez à un système complexe et que vous rencontrez un problème de design qui nécessite de refaire une partie de ce que vous avez fait. Plutôt que d'essayer de retrouver chaque modification que vous avez apporter pour la défaire (et généralement en oublier plein), vous pourrez simplement revenir a un commit précédent, où le soucis de design n'a pas encore été introduit. A chaque lot de modification de votre projet, une fois que vous en êtes satisfait, vous ferez alors un commit, qui est une sorte de sauvegarde de ces modifications et qui, cumulée à TOUS les commits (= lots de modification) précédents, permet à git de reconstruire l'état exacte du code au moment où le commit est fait (c'est foutrement bien fait !). Un commit se fait en local, sur votre ordinateur donc, et vous devrez ensuite envoyer vos commits à Github via un "push"
Push
L'opération inverse du pull. Ici, vous envoyer à Github vos modifications (synchronisation local -> origin). De la même façon, ça ne modifiera sur Github que ce que vous avez modifié, rien d'autre, ce qui permet à d'autres utilisateurs d'appliquer des modifications en parallèle ! Même si on y reviendra en détail, vous l'aurez compris rien qu'à ces définitions, l'idée est de d'abord pull pour se mettre à jour localement, puis modifier son code, commit à chaque fois qu'on fait une avancée satisfaisante, puis push une fois la fonctionnalité implémenté !
Premiers pas
Ici on va apprendre à utiliser Git au travers des outils suivants :
Beta Was this translation helpful? Give feedback.
All reactions