git.pdf

Git
Git est un système de contrôle de version.
Git vous aide à suivre les changements de code.
Git est utilisé pour collaborer sur du code.
Apprendre par des exemples
Dans ce cours, nous allons vous montrer des commandes Git comme celle-
ci :
Pour les nouveaux utilisateurs, l'utilisation de la vue terminal peut sembler
un peu compliquée. Ne vous inquiétez pas! Nous allons le garder très
simple, et apprendre de cette façon vous donne une bonne compréhension
du fonctionnement de Git.
Formateur Jaouad Assabbour

Dépôts Git et distants
Git et GitHub sont des choses différentes.
Dans ce tutoriel, vous comprendrez ce qu'est Git et comment l'utiliser sur
les plates-formes de référentiel distant, comme GitHub.
Qu'est-ce que Git ?
Git est un système de contrôle de version populaire. Il a été créé par Linus
Torvalds en 2005 et est maintenu par Junio Hamano depuis lors.
Il est utilisé pour :
• Modifications du code de suivi
• Suivre qui a apporté des modifications
• Codage collaboratif
Que fait Git ?
• Gérer des projets avec les référentiels
• Cloner un projet pour travailler sur une copie locale
• Contrôlez et suivez les modifications avec Staging et Committing
• Branchez et fusionnez pour permettre de travailler sur différentes
parties et versions d'un projet
• Tirez la dernière version du projet vers une copie locale
• Pousser les mises à jour locales vers le projet principal

Travailler avec Git
• Initialiser Git sur un dossier, en en faisant un référentiel
• Git crée maintenant un dossier caché pour garder une trace des
modifications dans ce dossier
• Lorsqu'un fichier est modifié, ajouté ou supprimé, il est considéré
comme modifié
• Vous sélectionnez les fichiers modifiés que vous souhaitez mettre en
scène
• Les fichiers Staged sont Committed , ce qui invite Git à stocker un
instantané permanent des fichiers
• Git vous permet de voir l'historique complet de chaque commit.
• Vous pouvez revenir à n'importe quel commit précédent.
• Git ne stocke pas une copie séparée de chaque fichier dans chaque
commit, mais garde une trace des modifications apportées à chaque
commit !
Pourquoi Git ?
• Plus de 70% des développeurs utilisent Git !
• Les développeurs peuvent travailler ensemble de n'importe où dans le
monde.
• Les développeurs peuvent voir l'historique complet du projet.

• Les développeurs peuvent revenir aux versions antérieures d'un
projet.
Qu'est-ce que GitHub ?
• Git n'est pas la même chose que GitHub.
• GitHub crée des outils qui utilisent Git.
• GitHub est le plus grand hôte de code source au monde et appartient
à Microsoft depuis 2018.
• Dans ce cours, nous allons nous concentrer sur l'utilisation de Git
avec GitHub.

Installer Git
Vous pouvez télécharger Git gratuitement sur le site suivant :
https://www.git-scm.com/
Utilisation de Git avec la ligne de commande
Pour commencer à utiliser Git, nous allons d'abord ouvrir notre shell de
commande.
Pour Windows, vous pouvez utiliser Git bash, qui est inclus dans Git pour
Windows. Pour Mac et Linux, vous pouvez utiliser le terminal intégré.
La première chose que nous devons faire est de vérifier si Git est
correctement installé :
Si Git est installé, il devrait afficher quelque chose comme git version X.Y

Configurer Git
Faites maintenant savoir à Git qui vous êtes. Ceci est important pour les
systèmes de contrôle de version, car chaque commit Git utilise ces
informations :
Remplacez le nom d'utilisateur et l'adresse e-mail par les vôtres. Vous
voudrez probablement également l'utiliser lors de votre inscription
ultérieure à GitHub.
Remarque : Utilisez global pour définir le nom d'utilisateur et
l'adresse e-mail pour chaque référentiel sur votre ordinateur.
Si vous souhaitez définir le nom d'utilisateur/e-mail uniquement pour le
référentiel actuel, vous pouvez supprimer global

Création du dossier Git
Maintenant, créons un nouveau dossier pour notre projet :
mkdir créer un nouveau répertoire .
cd change le répertoire de travail courant .
Maintenant que nous sommes dans le bon répertoire. Nous pouvons
commencer par initialiser Git !
Remarque : Si vous avez déjà un dossier/répertoire que vous souhaitez
utiliser pour Git :
Accédez-y en ligne de commande ou ouvrez-le dans votre explorateur de
fichiers, cliquez avec le bouton droit de la souris et sélectionnez "Git Bash
ici"

Initialiser Git
Une fois que vous avez navigué vers le bon dossier, vous pouvez initialiser
Git sur ce dossier :
Vous venez de créer votre premier référentiel Git !
Remarque : Git sait maintenant qu'il doit surveiller le dossier sur lequel
vous l'avez lancé.
Git crée un dossier caché pour garder une trace des modifications.

Git Ajout de nouveaux fichiers
Vous venez de créer votre premier référentiel Git local. Mais c'est vide.
Alors ajoutons quelques fichiers ou créons un nouveau fichier à l'aide de
votre éditeur de texte préféré. En suite, enregistrez-le ou déplacez-le dans
le dossier que vous venez de créer.
Pour cet exemple, je vais utiliser un simple fichier HTML comme celui-ci :
Et enregistrez-le dans notre nouveau dossier en tant que index.html.
Revenons au terminal et listons les fichiers dans notre répertoire de travail
actuel :
ls listera les fichiers du répertoire. Nous pouvons voir que index.html c'est là.

Ensuite, nous vérifions le Git status et voyons s'il fait partie de notre référentiel :
Maintenant, Git est au courant du fichier, mais ne l'a pas ajouté à notre
référentiel !
Les fichiers de votre dossier de dépôt Git peuvent être dans l'un des 2 états
suivants :
• Tracked - fichiers connus de Git et ajoutés au référentiel
• Untracked - fichiers qui se trouvent dans votre répertoire de
travail, mais qui ne sont pas ajoutés au référentiel
Lorsque vous ajoutez pour la première fois des fichiers à un référentiel
vide, ils sont tous Untracked. Pour que Git les Tracked, vous devez
les mettre en scène ou les ajouter à l'environnement de mise en scène.
Nous couvrirons l'environnement de mise en scène dans le chapitre
suivant.

Git Environment
L'une des fonctions principales de Git est les concepts d'environnement de
staging et de commit.
Pendant que vous travaillez, vous pouvez ajouter, modifier et supprimer
des fichiers. Mais chaque fois que vous atteignez un jalon ou terminez une
partie du travail, vous devez ajouter les fichiers à un environnement de
staging.
Les fichiers préparés sont des fichiers prêts à être validés dans le
référentiel sur lequel vous travaillez. Vous en saurez plus prochainement
sur le commit.
Pour l'instant, nous avons fini de travailler avec index.html. Nous
pouvons donc l'ajouter à l'environnement de staging :
Le fichier doit être Staged . Vérifions l'état :
Maintenant, le fichier a été ajouté à l'environnement de staging.

Git ajouter plus d'un fichier
Vous pouvez également organiser plusieurs fichiers à la fois. Ajoutons 2
autres fichiers à notre dossier de travail. Utilisez à nouveau l'éditeur de
texte.
Un README.md fichier décrivant le référentiel (recommandé pour tous
les référentiels).
Une feuille de style externe de base ( bluestyle.css) :

Et mettez à jour index.html pour inclure la feuille de style :
Ajoutez maintenant tous les fichiers du répertoire actuel à l'environnement
de staging :

L'utilisation –all à la place des noms de fichiers individuels entraînera
stage tous les fichiers de modifications (nouveaux, modifiés et
supprimés).
Maintenant, les 3 fichiers sont ajoutés à l'environnement de staging et nous
sommes prêts à faire notre premier fichier commit.
Remarque : La commande raccourcie pour git add –all est git
add -A

Git Commit
Puisque nous avons terminé notre travail, nous sommes prêts à passer de
stage à commit pour notre repo.
L'ajout de commits permet de suivre nos progrès et nos changements au
fur et à mesure que nous travaillons. Git considère chaque commit point
de changement ou "point de sauvegarde". C'est un point du projet auquel
vous pouvez revenir si vous trouvez un bogue ou si vous souhaitez
apporter une modification.
Lorsque nous commit, nous devrions toujours inclure un message .
En ajoutant des messages clairs à chacun commit, il est facile pour vous
(et pour les autres) de voir ce qui a changé et quand.
La commit commande effectue une validation et ajoute un message.-m
"message"
L'environnement de mise en scène a été engagé dans notre référentiel, avec
le message :
"Première version de Hello World !"

Git Commit sans étape
Parfois, lorsque vous apportez de petites modifications, l'utilisation de
l'environnement de staging semble être une perte de temps. Il est possible
de valider directement les modifications, en sautant l'environnement de
staging. L' -a option mettra automatiquement en scène chaque fichier
modifié et déjà suivi.
Ajoutons une petite mise à jour à index.html :
Et vérifiez l'état de notre référentiel. Mais cette fois, nous utiliserons
l'option --short pour voir les changements de manière plus compacte :

Remarque : les indicateurs d'état courts sont :
• ?? - Fichiers Untracked
• A - Fichiers ajoutés à l'étape
• M - Fichiers modifiés
• D - Fichiers supprimés
Nous voyons que le fichier que nous attendions est modifié. Alors
engageons-le directement :
Avertissement : Ignorer l'environnement de transfert n'est généralement
pas recommandé.
Sauter l'étape de l'étape peut parfois vous amener à inclure des
modifications indésirables.
Git Commit Log
Pour afficher l'historique des commits d'un dépôt, vous pouvez utiliser la
commande log:

Git Help
Si vous rencontrez des difficultés pour vous souvenir des commandes ou
des options des commandes, vous pouvez utiliser Git help.
Il existe plusieurs façons d'utiliser la commande help en ligne de
commande :
• git command --help Voir toutes les options disponibles pour
la commande spécifique
• git help -–all Voir toutes les commandes possibles

Passons en revue les différentes commandes.
Git -help Voir les options d'une commande spécifique
Chaque fois que vous avez besoin d'aide pour vous souvenir de l'option
spécifique d'une commande, vous pouvez utiliser : git command -
help

Remarque : vous pouvez également utiliser à la
place --help de -help pour ouvrir la page de
manuel Git correspondante

Git Branch
Travailler avec les branches Git
Dans Git, a branch est une nouvelle version/séparée du référentiel
principal.
Disons que vous avez un grand projet et que vous devez mettre à jour la
conception.
Comment cela fonctionnerait-il sans et avec Git :
Sans Git :
• Faites des copies de tous les fichiers pertinents pour ne pas impacter
la version live
• Commencez à travailler avec la conception et constatez que le code
dépend du code dans d'autres fichiers, qui doivent également être
modifiés !
• Faites également des copies des fichiers dépendants. S'assurer que
chaque dépendance de fichier fait référence au nom de fichier correct
• URGENCE! Il y a une erreur sans rapport ailleurs dans le projet qui
doit être corrigée dès que possible !
• Enregistrez tous vos fichiers en notant les noms des copies sur
lesquelles vous travailliez
• Travaillez sur l'erreur non liée et mettez à jour le code pour le
corriger
• Revenez à la conception et terminez le travail là-bas
• Copiez le code ou renommez les fichiers, de sorte que la conception
mise à jour soit sur la version en direct
• (2 semaines plus tard, vous réalisez que l'erreur non liée n'a pas été
corrigée dans la nouvelle version de conception car vous avez copié
les fichiers avant le correctif)

Avec Git :
• Avec une nouvelle branche appelée new-design, éditez le code
directement sans impacter la branche principale
• URGENCE! Il y a une erreur sans rapport ailleurs dans le projet qui
doit être corrigée dès que possible !
• Créez une nouvelle branche à partir du projet principal appelée
small-error-fix
• Corrigez l'erreur non liée et fusionnez la branche small-error-fix avec
la branche principale
• Vous retournez à la branche new-design et y terminez le travail
• Fusionner la branche new-design avec main (être alerté du petit
correctif d'erreur qui vous manquait)
Les branches vous permettent de travailler sur différentes parties d'un
projet sans impact sur la branche principale.
Lorsque le travail est terminé, une branche peut être fusionnée avec le
projet principal.
Vous pouvez même basculer entre les branches et travailler sur différents
projets sans qu'ils n'interfèrent les uns avec les autres.
La création de branches dans Git est très légère et rapide !

Nouvelle branche Git
Ajoutons quelques nouvelles fonctionnalités à notre page index.html.
Nous travaillons dans notre référentiel local et nous ne voulons pas
perturber ou éventuellement détruire le projet principal.
Nous créons donc une nouvelle branche:
Maintenant, nous avons créé une nouvelle branche nommé " hello-
world-images"
Confirmons que nous avons créé une nouvelle branche:
Nous pouvons voir la nouvelle branche avec le nom "hello-world-images",
mais le *côté master précise que nous sommes actuellement sur celle-
ci branch.
Checkout est la commande utilisée pour extraire un fichier branch.
Nous déplaçant du courant branch vers celui spécifié à la fin de la
commande :

Nous avons maintenant déplacé notre espace de travail actuel de la
branche master vers la nouvelle branch
Ouvrez votre éditeur préféré et apportez quelques modifications.
Pour cet exemple, nous avons ajouté une image (img_hello_world.jpg) au
dossier de travail et une ligne de code dans le fichier index.html :
Nous avons apporté des modifications à un fichier et ajouté un nouveau
fichier dans le répertoire de travail (même répertoire que le main
branch).
Vérifiez maintenant l'état du courantbranch :

Passons donc en revue ce qui se passe ici :
• Des modifications ont été apportées à notre fichier index.html, mais
le fichier n'est pas préparé pour commit
• img_hello_world.jpg n'est pas tracked
Nous devons donc ajouter les deux fichiers à l'environnement de staging
pour cela branch :
Utiliser –all à la place des noms de fichiers individuels mettra en scène
tous les fichiers modifiés (nouveaux, modifiés et supprimés).
Vérifiez status les branch:
Nous sommes satisfaits de nos changements. Nous allons donc les engager
dans branch:

Nous avons maintenant une nouvelle branch, qui est différent du
branch Master.
Remarque : L'utilisation de l' -boption on checkout créera une
nouvelle branche et se déplacera vers elle si elle n'existe pas
Switching Between Branches
Voyons maintenant à quel point il est rapide et facile de travailler avec différentes
branches, et à quel point cela fonctionne.
Nous sommes actuellement sur la branche hello-world-images. Nous avons
ajouté une image à cette branche, listons donc les fichiers dans le répertoire courant :
Nous pouvons voir le nouveau fichier img_hello_world.jpg, et si
nous ouvrons le fichier html, nous pouvons voir que le code a été modifié.
Tout est comme il se doit.
Voyons maintenant ce qui se passe lorsque nous changeons de branche en
master

La nouvelle image ne fait pas partie de cette branche. Listez à nouveau les
fichiers du répertoire courant :
img_hello_world.jpg n'est plus là ! Et si nous ouvrons le fichier
html, nous pouvons voir le code revenir à ce qu'il était avant la
modification.
Vous voyez à quel point il est facile de travailler avec des succursales ? Et
en quoi cela vous permet de travailler sur des choses différentes ?

Emergency Branch
Imaginons maintenant que nous n'en ayons pas encore fini avec hello-
world-images, mais que nous devions corriger une erreur sur master.
Je ne veux pas jouer directement avec master, et je ne veux pas jouer avec
hello-world-images, puisque ce n'est pas encore fait.
Nous créons donc une nouvelle branche pour faire face à emergement :
Maintenant, nous avons créé une nouvelle branche à partir de master et y
avons changé. Nous pouvons corriger l'erreur en toute sécurité sans
déranger les autres branches.
Corrigeons notre erreur imaginaire :

Nous avons apporté des modifications à ce fichier et nous devons
transférer ces modifications dans la branche master.
Vérifiez l'état :
mettez le fichier en commit et validez :
Nous avons maintenant un correctif prêt pour master et nous devons
fusionner les deux branches.

Git Branch Merge
Fusionner les branches
Nous avons le emergency fix, alors fusionnons les branches master et
emergency-fix.
Tout d'abord, nous devons passer à la branche master :
Maintenant, nous fusionnons la branche actuelle (Master) avec le
emergency-fix :
Étant donné que la branche de correction d'urgence provenait directement
de master et qu'aucune autre modification n'avait été apportée à master
pendant que nous travaillions, Git considère cela comme une continuation
de master. Ainsi, il peut "avancer rapidement", en pointant simplement le
maître et le emergency-fix vers le même commit.
Comme le master et le emergency-fix sont essentiellement les mêmes
maintenant, nous pouvons supprimer le emergency-fix , car il n'est plus
nécessaire :

Merge Conflict
Maintenant, nous pouvons passer à hello-world-images et continuer à
travailler. Ajoutez un autre fichier image (img_hello_git.jpg) et modifiez
index.html pour qu'il s'affiche
Maintenant, nous avons terminé notre travail ici et pouvons organiser et
valider pour cette branche :

Nous voyons que index.html a été modifié dans les deux branches. Nous
sommes maintenant prêts à fusionner hello-world-images dans master.
Mais qu'adviendra-t-il des changements que nous avons récemment
apportés à master ?
La fusion a échoué, car il existe un conflit entre les versions de index.html.
Vérifions l'état :
Cela confirme qu'il y a un conflit dans index.html, mais les fichiers image
sont prêts et préparés pour être validés.

Nous devons donc résoudre ce conflit. Ouvrez le fichier dans notre
éditeur :
Nous pouvons voir les différences entre les versions et les modifier comme
nous le souhaitons :

Nous pouvons maintenant mettre en commit index.html et vérifier l'état :
Le conflit a été corrigé et nous pouvons utiliser commit pour conclure la
fusion :
Et supprimez la branche hello-world-images :
Vous avez maintenant une meilleure compréhension du fonctionnement
des branches et de la fusion. Il est temps de commencer à travailler avec
un référentiel distant !

Git GitHub Premiers pas
Compte GitHub
Allez sur www.gitbub.com et créez un compte :
Remarque : N'oubliez pas d'utiliser la même adresse e-mail que celle que
vous avez utilisée dans la configuration Git.

Créer un référentiel sur GitHub
Maintenant que vous avez créé un compte GitHub, connectez-vous et
créez un nouveau Repo :

Et remplissez les détails pertinents:
Nous reviendrons sur les différentes options et ce qu'elles signifient plus
tard. Mais pour l'instant, choisissez Public (si vous voulez que le dépôt soit
visible pour tout le monde) ou Privé (si vous voulez choisir qui doit
pouvoir voir le dépôt). Dans tous les cas, vous pourrez choisir qui peut
contribuer au dépôt.
Cliquez ensuite sur "Créer un référentiel".

Pousser le référentiel local vers GitHub
Puisque nous avons déjà mis en place un dépôt Git local, nous allons
push vers GitHub :
Copiez l'URL ou cliquez sur le presse-papiers marqué dans l'image ci-
dessus.
Collez-y maintenant la commande suivante :
git remote add origin URL spécifie que vous ajoutez un
référentiel distant, avec le spécifié URL, en tant que origin à votre
référentiel Git local.

Nous allons maintenant pousser notre branche principale vers l'url d'origine et
la définir comme branche distante par défaut :
Remarque : étant donné que c'est la première fois que vous vous
connectez à GitHub, vous recevrez une sorte de notification vous
permettant d'authentifier cette connexion.

Maintenant, retournez dans GitHub et voyez que le référentiel a été mis à
jour :

Modifier le code dans GitHub
En plus d'être un hébergeur de contenu Git, GitHub dispose d'un très bon
éditeur de code.
Essayons de modifier le fichier README.md dans GitHub. Cliquez
simplement sur le bouton Modifier :

Ajoutez quelques modifications au code, puis commitles modifications.
Pour l'instant, nous allons "Commiter directement dans la branche master".
N'oubliez pas d'ajouter une description pour commit:
C'est ainsi que vous modifiez le code directement dans GitHub !

Git Pull de GitHub
Tirer pour se tenir au courant des changements
Lorsque vous travaillez en équipe sur un projet, il est important que tout le
monde reste à jour.
Chaque fois que vous commencez à travailler sur un projet, vous devriez
obtenir les modifications les plus récentes sur votre copie locale.
Avec Git, vous pouvez le faire avec pull.
Pull est une combinaison de 2 commandes différentes :
• fetch
• merge
Examinons de plus près le fonctionnement fetch , merge et pull.

Git Fetch
Fetch obtient tout l'historique des modifications d'une branche/dépôt
suivi.
Donc, sur votre Git local, faites des fetch mises à jour pour voir ce qui
a changé sur GitHub :
Maintenant que nous avons le récent changes, nous pouvons vérifier
notre status:

Nous sommes en retard origin/master de un commit. Cela devrait
être la mise à jour README.md, mais permet de vérifier en consultant le
log:
Cela ressemble à ce que nous attendions, mais nous pouvons également
vérifier en montrant les différences notre local master et
origin/master:
Cela ressemble exactement à ce que nous attendions ! Maintenant, nous
pouvons en toute sécurité merge

Git Merge
Merge combine la branche actuelle avec une branche
spécifiée.
Nous avons confirmé que les mises à jour sont comme prévu, et nous
pouvons fusionner notre branche actuelle ( master) avec
origin/master:
Vérifiez status à nouveau notre pour confirmer que
nous sommes à jour :
Là! Votre git local est à jour !

Git-Pull
Mais que se passe-t-il si vous souhaitez
simplement mettre à jour votre référentiel local,
sans passer par toutes ces étapes ?
Pull est une combinaison de fetch et merge. Il est utilisé pour
extraire toutes les modifications d'un référentiel distant dans la branche sur
laquelle vous travaillez.
Apportez une autre modification au fichier Readme.md sur GitHub.

Utilisez pull pour mettre à jour notre Git local :
C'est ainsi que vous maintenez votre Git local à
jour à partir d'un référentiel distant. Dans le
prochain chapitre, nous verrons de plus près
comment push fonctionne avec GitHub.

Git Push to GitHub
Essayons d'apporter quelques modifications à notre
git local et de les pousser vers GitHub.
Validez les modifications :
Et vérifiez l'état :

Poussez maintenant nos modifications vers notre
origine distante :
Accédez à GitHub et confirmez que le dépôt a un
nouveau commit :
Maintenant, nous allons commencer à travailler sur
les branches sur GitHub.

Git GitHub Branch
Créer une nouvelle branche sur GitHub
Sur GitHub, accédez à votre référentiel et cliquez sur le bouton de branche
"master".
Là, vous pouvez créer une nouvelle branche. Tapez un nom descriptif et
cliquez sur Créer une branche

Le branch devrait maintenant être créé et actif.
Vous pouvez confirmer sur quelle branche vous
travaillez en regardant le bouton de branche. Vous
voyez qu'il est maintenant écrit "squelette html"
au lieu de "main" ?

Commencez à travailler sur un fichier existant
dans cette branche. Cliquez sur le fichier
index.html " " et commencez à éditer :

Une fois que vous avez terminé de modifier le
fichier, vous pouvez cliquer sur l'onglet "Aperçu
des modifications" pour voir les modifications
apportées en surbrillance :

Si vous êtes satisfait de la modification, ajoutez
un commentaire expliquant ce que vous avez fait,
puis cliquez sur Valider les modifications.
Vous avez maintenant une nouvelle branche sur GitHub, mis à jour
avec quelques changements !

Git Pull Branch from GitHub
Continuez maintenant à travailler sur notre new
branchdans notre Git local.
Reprenons pull notre référentiel GitHub pour que notre code soit à
jour :
Maintenant, notre principal branch est à jour. Et
on peut voir qu'il y en a une nouvelle branch
disponible sur GitHub.
Faites une status vérification rapide :
Et confirmez quelles succursales nous avons et où nous travaillons en ce
moment :

Donc, nous n'avons pas la nouvelle branche sur
notre Git local. Mais nous savons qu'il est
disponible sur GitHub. Nous pouvons donc utiliser
l' option -a pour voir toutes les branches locales
et distantes :
Remarque : branch -r concerne uniquement les
succursales distantes.
Nous voyons que la branche html-skeleton est
disponible à distance, mais pas sur notre git
local. Regardons ça:
Et vérifiez si tout est à jour :

Quelles succursales avons-nous maintenant et d'où
travaillons-nous ?
Maintenant, ouvrez votre éditeur préféré et
confirmez que les modifications de la branche
GitHub ont été transférées.
C'est ainsi que vous tirez une branche GitHub vers votre Git local.

Git Push Branch to GitHub
Essayons de créer une nouvelle branche locale et de la pousser vers
GitHub.
Commencez par créer une branche, comme nous l'avons fait
précédemment :
Et nous apportons quelques modifications au fichier README.md.
Ajoutez simplement une nouvelle ligne.
Alors maintenant, nous vérifions le status de la branche actuelle.
Nous voyons que README.md est modifié mais pas
ajouté à l'environnement de staging :

Vérifiez status de la branche :
Nous sommes satisfaits de nos changements. Alors
nous allons commit au branch:
Maintenant push : branch, depuis notre référentiel
Git local, vers GitHub, où tout le monde peut voir
les modifications

Allez sur GitHub et confirmez que le dépôt a un
nouveau branch:
Dans GitHub, nous pouvons maintenant voir les
modifications intégrer et les merge au branch
Master si nous l'approuvons.

Si vous cliquez sur "Compare & pull request", vous
pouvez passer en revue les modifications apportées
et les nouveaux fichiers ajoutés :
Remarque : cette comparaison montre à la fois les
modifications depuis update-readme et html-skeletonparce que nous
avons créé la nouvelle branche FROM html-skeleton.

Si les changements semblent bons, vous pouvez
continuer en créant un pull request:
Une demande d'extraction est la façon dont vous
proposez des modifications. Vous pouvez demander à
certains de revoir vos modifications ou d'extraire
votre contribution et de la fusionner dans leur
branche.

Puisqu'il s'agit de votre propre référentiel, vous
pouvez vous merge même effectuer votre pull
request :
La demande d'extraction enregistrera les
modifications, ce qui signifie que vous pourrez
les parcourir plus tard pour comprendre les
modifications apportées.

Le résultat devrait ressembler à ceci :

Pour éviter que le dépôt ne devienne trop
compliqué, vous pouvez supprimer la branche
désormais inutilisée en cliquant sur "Supprimer la
branche".
Une fois que vous avez confirmé que les
modifications de la branche précédente ont été
incluses, supprimez-les également :

Git GitHub Flow
Travailler avec le flux GitHub
Sur cette page, vous apprendrez comment tirer le meilleur parti de votre
travail avec GitHub.
Le flux GitHub est un flux de travail conçu pour bien fonctionner avec Git
et GitHub.
Il se concentre sur la ramification et permet aux équipes d'expérimenter
librement et de faire des déploiements régulièrement.
Le flux GitHub fonctionne comme ceci :
• Créer une nouvelle branche
• Apporter des modifications et ajouter des commits
• Ouvrir une demande d'extraction
• Examen
• Déployer
• Fusionner
Vous devriez déjà avoir une bonne compréhension de la façon dont cela
fonctionne à partir des chapitres précédents. Ce chapitre se concentre sur la
compréhension de la façon dont le flux vous permet de travailler
facilement ensemble.

Créer une nouvelle branche
La création de branches est le concept clé de Git. Et cela fonctionne autour
de la règle selon laquelle la branche master est TOUJOURS déployable.
Cela signifie que si vous voulez essayer quelque chose de nouveau ou
expérimenter, vous créez une nouvelle branche ! La création de branches
vous offre un environnement dans lequel vous pouvez apporter des
modifications sans affecter la branche principale.
Lorsque votre nouvelle branche est prête, elle peut être examinée, discutée
et fusionnée avec la branche principale lorsqu'elle est prête.
Lorsque vous créez une nouvelle branche, vous voudrez (presque toujours)
la créer à partir de la branche master.
Remarque : Gardez à l'esprit que vous travaillez avec d'autres. Utiliser des noms
descriptifs pour les nouvelles branches, afin que chacun puisse comprendre ce qui se passe.

Apporter des modifications et ajouter des commits
Une fois la nouvelle branche créée, il est temps de se mettre au travail.
Apportez des modifications en ajoutant, modifiant et supprimant des
fichiers. Chaque fois que vous atteignez un petit jalon, ajoutez les
modifications à votre branche par commit.
L'ajout de commits permet de suivre votre travail. Chaque commit doit
avoir un message expliquant ce qui a changé et pourquoi. Chaque commit
devient une partie de l'historique de la branche et un point auquel vous
pouvez revenir si nécessaire.
Remarque : les messages de validation sont très importants ! Faites savoir à tout le
monde ce qui a changé et pourquoi. Les messages et les commentaires vous
permettent, à vous et aux autres, de suivre plus facilement les modifications.

Ouvrir une demande d'extraction (Pull Request)
Les demandes d'extraction sont un élément clé de GitHub. Une demande
d'extraction informe les personnes que vous avez des modifications prêtes
à être prises en compte ou révisées.
Vous pouvez demander à d'autres de revoir vos modifications ou d'extraire
votre contribution et de la fusionner dans leur branche.
Examen
Lorsqu'une demande d'extraction est effectuée, elle peut être examinée par
toute personne disposant d'un accès approprié à la branch. C'est là que se
produisent de bonnes discussions et un examen des changements.
Les Pull Requests sont conçues pour permettre aux gens de travailler
ensemble facilement et de produire de meilleurs résultats ensemble !
Si vous recevez des commentaires et que vous continuez à améliorer vos
modifications, vous pouvez pousser vos modifications avec de nouveaux
commits, ce qui rend possible d'autres révisions.
Remarque : GitHub affiche les nouveaux commits et les commentaires dans la "unified
Pull Request view".

Déployer
Lorsque la demande d'extraction a été examinée et que tout semble bon, il
est temps de procéder aux tests finaux. GitHub vous permet de déployer à
partir d'une branche pour les tests finaux en production avant de fusionner
avec la branche principale.
En cas de problème, vous pouvez annuler les modifications en déployant à
nouveau la branche principale en production !
Remarque : les équipes disposent souvent d'environnements de test dédiés utilisés pour déployer
des branches.
Fusionner (merge)
Après des tests exhaustifs, vous pouvez fusionner le code dans la branche
master !
Les demandes d'extraction conservent des enregistrements des
modifications apportées à votre code, et si vous avez bien commenté et
nommé les modifications, vous pouvez revenir en arrière et comprendre
pourquoi les modifications et les décisions ont été prises.
Remarque : Vous pouvez ajouter des mots-clés à votre pull request pour faciliter la recherche !

Git GitHub Fork
Ajouter au référentiel de quelqu'un.
Au cœur de Git se trouve la collaboration. Cependant, Git ne vous permet
pas d'ajouter du code au référentiel de quelqu'un d'autre sans droits d'accès.
Dans ces 3 prochains chapitres, nous vous montrerons comment copier un
référentiel, y apporter des modifications et suggérer que ces modifications
soient implémentées dans le référentiel d'origine.
A la fin de ces chapitres, vous aurez la possibilité d'ajouter un message sur
notre page publique GitHub : https://w3schools-
test.github.io/
Forker un référentiel
A fork est une copie d'un référentiel. Ceci est utile lorsque vous
souhaitez contribuer au projet de quelqu'un ou démarrer votre propre projet
basé sur le sien.
Fork n'est pas une commande dans Git, mais quelque chose offert dans
GitHub et d'autres hôtes de référentiel. Commençons par nous connecter à
GitHub et à fork notre référentiel:
https://github.com/w3schools-test/w3schools-test.github.io

Nous avons maintenant notre propre copie de
w3schools-test.github.io:
Voyons maintenant comment nous ajoutons une copie locale de ceci avec
laquelle nous pouvons travailler.

Clone a Fork from GitHub
Maintenant, nous avons notre propre fork, mais uniquement sur GitHub.
Nous voulons également un clone sur notre Git local pour continuer à
travailler dessus.
A clone est une copie complète d'un référentiel, y compris toute la
journalisation et les versions des fichiers.
Revenez au référentiel d' origine et cliquez sur le bouton vert "Code" pour
obtenir le URL à clone :
Ouvrez votre bash Git et clonele dépôt :

Jetez un œil à votre système de fichiers et vous verrez un nouveau
répertoire nommé d'après le projet cloné :
Remarque : Pour spécifier un dossier spécifique vers lequel cloner, ajoutez le nom du dossier
après le référentiel URL, comme ceci : git clone https://github.com/w3schools-
test/w3schools-test.github.io.git myfolder
Naviguez jusqu'au nouveau répertoire, et cochez status:
Et vérifiez le log pour confirmer que nous avons les données complètes
du référentiel :
Nous avons maintenant une copie complète du référentiel d'origine.

Configuration des Remotes
Fondamentalement, nous avons une copie complète d'un référentiel, auquel
origin nous ne sommes pas autorisés à apporter des modifications.
Voyons comment les remotes de ce Git est configuré :
Nous voyons que origin le dépôt " " d'origine est configuré
w3schools-test, nous souhaitons également ajouter nôtre fork.
Tout d'abord, nous rename l'original origin remote:
Ensuite, récupérez le URL nôtre fork :

Et ajouter cela comme origin:
Remarque : selon les conventions de nommage de Git, il est recommandé de
nommer votre propre référentiel originet celui que vous avez créé upstream
Maintenant nous avons 2 remotes :
• origin le nôtre fork, où nous avons un accès en lecture et en
écriture
• upstream - l'original, où nous avons un accès en lecture seule
Nous allons maintenant apporter quelques modifications au code. Dans le
chapitre suivant, nous expliquerons comment nous suggérons ces
modifications au référentiel d'origine.

Push Changes to Our GitHub Fork
Nous avons apporté de nombreuses modifications à notre Git local.
Maintenant, nous push les dirigeons vers notre GitHub fork:
commit les changements:
Allez sur GitHub, et nous voyons que le référentiel a un nouveau commit.
Et nous pouvons envoyer une demande d'extraction au référentiel d'origine
:

Cliquez dessus et créez une pull request :
N'oubliez pas d'ajouter une explication pour les administrateurs.

La Pull Request est envoyée :

Approbation des Pull Requests
Désormais, tout membre disposant d'un accès peut voir la pull requests
lorsqu'il voit le référentiel d'origine :
Et ils peuvent voir les modifications proposées :

Commentez les changements et merge:

Confirmer :

Et les changements ont été merged a master:
Fin merci pour votre attention
Jaouad assabbour
Formateu web

git.pdf

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à git.pdf

Similaire à git.pdf (20)

Plus de Jaouad Assabbour

Plus de Jaouad Assabbour (12)

git.pdf