Le choix de la commande à utiliser dépend de la façon dont vous souhaitez travailler.

Installer Git

un bon exemple: [1]

Assurer que git soit bien installé

git --version

Configurer son identité

La première chose à faire est de configurer son identité.

Commencer par renseigner votre nom et votre adresse e-mail. C'est une information importante car toutes les validations dans Git utilisent cette information et elle est indélébile dans toutes les validations que vous pourrez réaliser :

$ git config --global user.name "<prénom> <nom>"
$ git config --global user.email "<adresse@mail.tld>"

Grâce à l’option --global, vous n’aurez besoin de le faire qu'une fois.

Si vous souhaitez par contre, pour un projet spécifique, changer votre nom d’utilisateur, vous devrez repasser cette ligne mais sans le --global.

Afin de vérifier que vos paramètres aient bien été pris en compte, et vérifier les autres paramètres, il suffit de passer la commande git config --list

Activer la coloration syntaxique (optionnel)

Soit en automatique

git config --global color.ui auto

Soit, il est recommandé d’activer les couleurs afin d’améliorer la lisibilité des différentes branches. Pour cela, passez ces trois lignes dans Git Bash :

$ git config --global color.diff auto
$ git config --global color.status auto
$ git config --global color.branch auto

Par défaut, Git utilisera Vim comme éditeur et Vimdiff comme outil de merge. Vous pouvez les modifier en utilisant :

$ git config --global core.editor notepad++ $ git config --global merge.tool vimdiff

Créer un dépôt local

Pour ce faire, deux solutions possibles :

Créer un dépôt local vide pour accueillir un nouveau projet ;
Cloner un dépôt distant, c’est-à-dire rapatrier tout l’historique d’un dépôt distant en local, afin de pouvoir travailler par dessus.

Dans un logiciel de gestion de versions comme Git, un dépôt représente une copie du projet.
Chaque ordinateur d’un développeur qui travaille sur le projet possède donc une copie du dépôt.
Dans chaque dépôt, on trouve les fichiers du projet ainsi que leur historique.

- Etape 1: Créer un dépôt vide. On va créer, dans un premier temps, un dossier sur notre disque (avec le nom de notre projet).

(Vous pouvez créez un dossier manuellement ou avec une ligne de commande)

- Etape 2: Accédez à votre dossier, et lancez la ligne ci-dessous dans Git Bash en ciblant ce dossier :

Nonutilisateur ~
$ cd Documents/Fichiers/Git/NomdeVotrePremierProjet
Nonutilisateur ~/Documents/Fichiers/Git/NomdeVotrePremierProjet
$ git init
Initialized empty Git repository in c:/users/Nonutilisateur/Documents/Fichiers/Git/NomdeVotrePremierProjet/

- Etape 3: Rendre visible le fichier dépot Git : Votre dossier n’a rien de nouveau, mais c’est normal. :) Vous avez pourtant bien initialisé votre dépôt Git. Un dossier caché .git a été créé ! Vous pouvez l'afficher en allant dans Affichage => Éléments masqués.

Configurer un nouveau / existant projet (à faire dans le bon dossier)

$ git init

Voir les nouveaux fichiers créés, la branche actuelle,...

$ git status

Ajouter un fichier dans le repository

$ git add index.html
$ git commit -m 'premier commit de la page l\'accueil'

Cloner un repository

Pointer vers le dépôt distant

sur Git Bash, et tapez la commande suivante :

git remote add OC https://github.com/vous/votreProjet.git

Cette ligne ne permet pas de cloner le dépôt, mais permet de dire au dépôt que l’on pointe vers le dépôt distant.

REMARQUE IMPORTANTE: OC représente un nom court que vous avez choisi et que vous utiliserez ensuite pour appeler votre dépôt. Appelez-le comme bon vous semble, mais un nom court et simple est toujours plus facile.

La commande git-clone

A ce stade le dépôt local pointe sur le dépôt distant, il est possible de cloner son contenu et le dupliquer en local grâce à la commande git-clone. Cette commande utilise en premier argument l'adresse d'un repository.

git clone https://github.com/vous/votreProjet.git

Astuce: Si l'on n'indique pas le protocole avec le caractère : au début de l'adresse, il est possible de spécifier un répertoire du repository en utilisant ce caractère après l'adresse.

git clone git@github.com:monDossier

En utilisant cette commande, cela va créer un répertoire appelé monDossier dans lequel sera téléchargé le contenu du repository. Si vous souhaitez créer un répertoire spécifique, il suffit de l'indiquer en deuxième argument de la commande.

#Le contenu sera téléchargé dans le dossier où vous vous situez
git clone git@github.com:monDossier .

#Le contenu sera directement téléchargé dans le répertoire repertoire
git clone git@github.com:monDossier adressedurepertoire/repertoire

Remarques :

Si le répertoire existe déjà, il est obligatoire qu'il soit vide pour que la commande fonctionne.
Si vous souhaitez déplacer un dossier déjà téléchargé sur votre ordinateur, alors il est nécessaire de déplacer également le répertoire .git. En effectuant cette manipulation, vous vous assurez que les commandes git (git pull par exemple) continueront de fonctionner après le déplacement.

Système de branches

Le principal atout de Git est son système de branches. C’est sur ces branches que vont être réalisé les modifications sans toucher au codes et fichiers de votre projet initial. Les différentes branches correspondent à des copies de votre code principal à un instant T, où vous pourrez tester toutes vos idées les plus folles sans que cela impacte votre code principal. La branche va fonctionner comme un dossier virtuel.

Avec git branch, on va connaitre et créer les branches et vérifier la branche dans laquelle vous vous situez grâce à l'étoile (*)
Avec git checkout, on va être téléporté et passer de branches en branches
Avec git clone, on va cloner ou créer des branches
Avec git merge, on va fusionner des branches
....

dans le dossier virtuel Cagnotte. On reste dans le dossier OC physiquement, mais virtuellement nous sommes passés dans un monde parallèle ! Vous pouvez désormais réaliser votre évolution sans toucher à la branche master qui abrite votre code principal qui fonctionne. Vous pouvez rebasculer si besoin à tout moment sur la branche master, sans impacter les modifications de la branche Cagnotte.

Connaître les branches présentes dans notre projet

La ligne de commande :

git branch

Dans un nouveau projet, vous n’aurez que la réponse suivante:

git branch
* master

L’étoile signifie que c’est la branche sur laquelle vous vous situez et que c’est sur celle-ci qu'actuellement vous réalisez vos modifications. La racine de votre projet est la branche master

REMARQUE: Il est fortement conseillé de créer une branche et de ne pas travailler sur la branche master surtout si modification longue, complexes, ou que vous ne voyez pas tout de suite comment faire la modification.

Créer une branche

git branch <nom-nouvelle-branche>

Vérifier la branche dans laquelle vous vous situez

git branch

Changer de branche

git checkout <nom-branche>

Retourner dans la branche principale

git checkout master

Cloner une branche

Le système de gestion de versions Git permet d'administrer les différentes phases de développement de notre projet. Il est possible de cloner n'importe quelle branche du dépôt de votre projet. Il suffit pour cela d'utiliser la commande git clone

git clone git://example.com/monprojet

Mais une fois la branche clonée, si vous essayez de lister les branches avec la commande git branch, vous ne les verrez pas toutes. Pour être sûr de toutes les voir, il faut utiliser l'option -a. Exemple avec git branch :

git branch
* master

Exemple avec l'option -a :

git branch -a
* master
remotes/origin/HEAD
remotes/origin/master
remotes/origin/v1.0-stable
remotes/origin/experimental

Il est possible de récupérer une branche pour voir son contenu avec la commande git checkout. Si vous souhaitez travailler sur cette branche, il faut créer une branche locale avec l'option -b. Exemple :

git checkout -b experimental origin/experimental

Naviguer sur les branches interface graphique

Si vous avez trop de branches et que vous avez des difficultés pour vous y retrouver, la commande gitk permet de lancer une interface graphique capable de naviguer dans un dépôt git.

Commande pour lancer l'interface graphique :

gitk --all &

Fusionner une autre branche avec la principale

git merge <nom-branche>

Effacer une branche Git à la fois locale et distante

Vous pouvez supprimer complètement une branche au sein d'un dépôt Git. Il faut pour cela exécuter deux commandes.

Le logiciel Git fournit un système de branches en plus de la gestion des versions. Les branches permettent de travailler sur un élément à part dans un projet. On peut par exemple en créer une pour travailler sur une nouvelle fonctionnalité ou la résolution d'un problème. Lorsque le travail effectué sur la branche est terminé, on l'intègre dans le répertoire de travail principal grâce à la commande git merge.

Une fois le travail terminé sur une branche, vous pouvez la supprimer du dépôt. Il faut pour cela exécuter deux commandes, une pour chaque branche :

Supprimer branche local : celle qui existe en local sur votre ordinateur ;

celle qui existe sur le dépôt distant.

Pour supprimer une branche locale sur votre ordinateur, la commande est la suivante :

git branch -d [nom_de_la_branche]

Cette commande vous affichera un avertissement si la branche n'a pas été totalement fusionnée avec le répertoire principal du dépôt. Pour passer outre cet avertissement, on utilise l'option -D :

git branch -D [nom_de_la_branche]

Forcer la suppression de cette manière entraînera la suppression de tous les fichiers et modifications que nous n'aurez pas commités sur cette branche.

Supprimer branche distante : Pour supprimer la branche située sur le dépôt distant, la commande est différente selon la version de git utilisée.

- Si la version de Git est antérieure à la version 1.7.0, la syntaxe est la suivante :

git push [nom_du_depot_distant] :[nom_de_la_branche]

Si vous avez utilisé la commande git clone pour créer la branche, celle-ci attribue par défaut le nom origin au dépôt distant. La syntaxe de la commande devient :

git push origin :[nom_de_la_branche]

- Si vous utilisez une version de git plus récente, la syntaxe de la commande a été modifiée pour être plus facile à mémoriser :

git push origin --delete [nom_de_la_branche]

Une fois cette commande effectuée, vous devrez exécuter la commande suivante sur tous les autres ordinateurs afin de propager le changement :

git fetch --all -prune

Transférer les changements d'une branche à une autre

Git rebase a le même objectif que Git merge. Ces deux commandes permettent de transférer les changements d'une branche à une autre. Seule la manière de procéder va différer. Le rebase dispose de puissantes fonctionnalités de réécriture de l'historique. Il existe deux types de rebase : le rebase manuel et le rebase interactif. Au niveau du contenu, le rebase consiste à changer la base de votre branche d'un commit vers un autre, donnant l'illusion que vous avez créé votre branche à partir d'un commit différent. Git va prendre vos modifications d'une branche et les transposer sur une autre branche.

Réalisez un commit

La commande Git pull permet de récupérer en local le projet distant !
La commande Git push permet d'envoyer les modifications que l'on a réalisées en local sur le dépôt à distance;
La commande git add permet d'ajouter un fichier aux branches

L'index, ou stage, désigne tous les fichiers modifiés que vous souhaitez voir apparaître dans votre prochain commit.

Le dépôt local est l'historique de l'ensemble de vos actions (commits, configurations...). .

Et si on fait des erreurs ? Comment les réparer !

La commande commit : Permet l'archivage à un instant T
La commande git reflog: Permet d'accéder à l'historique de l'archivage (qui affichera toutes vos actions et leurs SHA. Le SHA, c'est ce grand code qui vous permettra de revenir à un commit exact. C'est l’identifiant de votre action !)

créez un nouveau dossier

Positionnez vous dedans avec la console. Vous ne voulez pas versionner l'intégralité de votre ordinateur en lançant git init dans un dossier comme "Mes Documents" ou "Applications" ! Une fois que vous vous êtes placés dans votre nouveau dossier grâce à la commande cd de votre Terminal, créez un nouveau dossier 'monPremierRepo' en lançant la commande suivante :

mkdir monPremierRepo

Vous remarquerez que j'ai appelé ce dossier 'Repo', qui est le petit nom de repository. car nous allons utiliser ce dossier comme repository, c'est-à-dire comme répertoire de travail géré par Git ! Voici un petit résumé des étapes à suivre :

Pour activer un dossier comme repository Git, il suffit de se placer dans ce dossier avec le Terminal puis d'utiliser la commande

git init.

Pour gérer un repository, Git génère un index de tous les fichiers dont il doit faire le suivi. Lorsque vous créez un fichier dans un repository, vous devez donc l'ajouter à l'index Git à l'aide de la commande

git add nomDeVotreFichier.extension.

Par exemple :

git add checklist-vacances.md

Pour gagner du temps, vous pouvez ajouter tous les fichiers dans le répertoire courant en tapant

git add .

Dans la console. Évidemment, faites bien attention quand vous utilisez ce raccourci à ne pas rajouter trop de fichiers à l'index.

Lorsque vous modifiez votre repository, vous devez demander à Git d'enregistrer vos modifications en faisant un

git commit

L'option-m vous permet de lui envoyer un message décrivant les modifications effectuées, ce qui s'avèrera très utile pour vous par la suite, Par exemple :

git commit -m "Ajouté ma checklist-vacances.md"

Votre premier commit est réalisée il représente un enregistrement (photo à un temps T qui garde les modifications) qui permettra de remonter dans le temps

Ajouter un premier fichier et le commiter (archiver)

Avant de créer une branche, vous devez créer votre branche principale (master). Pour créer la branche master, vous devez simplement ajouter un fichier et le commiter.

git add PremierFichier.txt
git commit

On vous demande alors d'indiquer le message du commit puis de valider. Pour valider le message, une fois que vous l'avez écrit, appuyez sur Echap (votre curseur va basculer sur la dernière ligne) et tapez :x. Cette commande va sauvegarder et quitter l'éditeur des messages de commit.

* Ajouter votre fichier à l'index avec la commande  git add,
git add checklist-vacances.md
* Faire un commit qui décrit la mise à jour de votre fichier avec la commande  git commit.
git commit -m "Ajouté itinéraire dans checklist-vacances.md"

Si vous ne faites que mettre à jour un fichier que vous aviez déjà ajouté à l'index, vous pouvez condenser ces deux étapes de la façon suivante :

git commit -a -m "Ajouté itinéraire dans checklist-vacances.md"

L'option -a demande à Git de mettre à jour les fichiers déjà existants dans son index. Pratique, non ?

Analyser vos derniers commits

git log,

Par défaut, git log va lister par ordre chronologique inversé tous vos commits réalisés avec leur info et surtout l'identifiant du commit que l'on appelle couramment le hash. (! Pour utiliser le hash il n'est pas nécessaire d'écrire l'identifiant en entier. Seuls les 8 premiers caractères sont nécessaires)

Changer le dernier commit

La fonction git --amend, permet de modifier le dernier commit.

Changer le message de mon commit

Lorsque l'on travaille sur un projet avec Git, il est très important, lorsque l'on propage les modifications, de bien marquer dans le message descriptif les modifications que l'on a effectuées. Si jamais vous faites une erreur dans l'un de vos messages de commit, il est tout à fait possible de changer le message après coup.

Attention ! Cette commande va fonctionner pour le dernier commit réalisé !

Imaginons que vous veniez de faire un commit et que vous ayez fait une erreur dans votre message. L'exécution de cette commande, lorsqu'aucun élément n'est encore modifié, vous permet de modifier le message du commit précédent sans modifier son instantané. L'option -m permet de transmettre le nouveau message.

git commit --amend -m "Votre nouveau message de commit"

-m (indique que l'amend est relative au message)

Et on vérifie avec

git log

Ajouter un fichier oublier a mon commit

Vous avez fait un commit et vous avez oublié de mettre un fichier, mais vous ne voulez pas changer tout le commit

Dans un premier temps ajouter le fichier oublié

git add FichierOublie.txt

Dans un deuxième temps réaliser un git --amend.

git commit --amend --no-edit

Votre fichier a été ajouté à votre commit et grâce à la commande --no-edit ajoutée (sans pour autant modifier les autres éléments du commit (message, hash,..).

Pour résumer, git commit --amend permet de sélectionner le dernier commit afin d'y ajouter de nouveaux changements en attente. Vous pouvez ajouter ou supprimer des changements

Déplacer un commit d'une branche master vers une nouvelle branche

Aller sur la branche master

Vérifiez bien que vous êtes sur votre branche master

Analyser et récupérer l'identifiant du derniers commits

git log

Les identifiants des commits que l'on appelle couramment les hash sont lister par ordre chronologique inversé.

Supprimer de la branche master votre dernier commit

git reset --hard HEAD^

Cette ligne de commande va permettre de supprimer de la branche master votre dernier commit. Le Head^ indique que c'est bien le dernier commit que nous voulons supprimer.

Créer une branche (autre que la master)

git branch <nomdelanouvellebranche>

Pour vérifier la création de cette banche:

git branch

Basculer sur cette branche

git checkout <nondelanouvellebranche>

Appliquer l'ancien commit sur une nouvelle branche

git reset --hard <mettreleschiffredelanciencommite>

le commit est donc transférer

! Il n'est pas nécessaire d'écrire l'identifiant en entier. Seuls les 8 premiers caractères sont nécessaires.

Annuler un commit en créant un nouveau commit

Ou comment corrigez vos erreurs en local et à distance ? Ou comment réparer un pushé des fichiers erronés ?

Deux solutions:

Il est possible d'annuler son commit public avec la commande Git revert.
Il est possible d'annuler son commit privé avec la commande git reset

- L'opération Revert annule un commit en créant un nouveau commit. C'est une méthode sûre pour annuler des changements, car elle ne risque pas de réécrire l'historique du commit.

git revert HEAD^

En revertant notre dernier commit public cela a créé un nouveau commit d'annulation. Cette commande n'a donc aucun impact sur l'historique ! Par conséquent, il vaut mieux utiliser git revert pour annuler des changements apportés à une branche publique, mais un git reset pour faire de même, mais sur une branche privée.

* Gardez à l'esprit que Git revert sert à annuler des changements commités, tandis que Git reset HEAD permet d'annuler des changements non commités.
* Toutefois, attention, Git revert peut écraser vos fichiers dans votre répertoire de travail, il vous sera donc demandé de commiter vos modifications ou de les remiser.

Duppiquer des commits

La gestion des modifications entre plusieurs branches de Git peut devenir une tâche complexe. Parfois, vous ne voulez pas fusionner une branche entière dans une autre et vous n'avez besoin que de choisir un ou deux commits spécifiques. Ce processus s'appelle cherry-pick ! Attention, Git cherry-pick n'est pas très apprécié dans la communauté des développeurs ! En effet, cette commande va dupliquer des commits existants. Il sera préférable, si possible, de réaliser un merge.

Admettons que vous travailliez sur votre branche "Mes évolutions", et que vous ayez déjà réalisé plusieurs commits. Votre collègue a besoin de l'une de ces évolutions pour la livrer au client, mais pas des autres. C'est dans ce cas bien précis que nous allons faire appel à git cherry-pick ! Cette commande va permettre de sélectionner un ou plusieurs commits grâce à leurs SHA et de les migrer sur la branche master, sans pour autant fusionner toute la branche "Mes évolutions".

git cherry-pick d356940 de966d4

Ici, nous prenons les deux commits ayant pour SHA d356940 et de966d4, et nous les ajoutons à la branche master sans pour autant les enlever de votre branche actuelle. Nous les dupliquons !

Avoir un résumé des changements effectués sur les fichiers locaux

git diff

Avoir une comparaison des fichiers ligne par ligne

git diff --color-words

Voir le fichier de log

git log

Voir le fichier de log plus succint

git log --oneline

Examiner le contenu d’un fichier ligne par ligne

La commande git blame permet d’examiner le contenu d’un fichier ligne par ligne et de déterminer la date à laquelle chaque ligne a été modifiée, et le nom de l’auteur des modifications.

git blame monFichier.php

git blame va afficher pour chaque ligne modifiée, son ID, l'auteur, l'horodatage, le numéro de la ligne et le contenu de la ligne.

Types de réinitialisation de Git

La commande git reset est un outil complexe et polyvalent pour annuler les changements. Elle peut être appelée de trois façons différentes, qui correspondent aux arguments de ligne de commande --soft, --mixed et --hard.

Restaurer un fichier modifié par sa version précédente

git checkout <nom-fichier>

Restauration dépôt, index et répertoire de travail

Comment tout recommencer et tout effacer ?

git reset --hard <reference-commit>

Permet de revenir à n'importe quel commit mais en oubliant absolument tout ce qu'il s'est passé après ! Cette commande est incontournable lorsque vous voulez tout recommencer.

Restauration dépôt et index

git reset --mixed <reference-commit>

Permet de revenir juste après votre dernier commit ou le commit spécifié, sans supprimer vos modifications en cours. Il va par contre créer un HEAD détaché. Il permet aussi, dans le cas de fichiers indexés mais pas encore commités, de désindexer les fichiers.

git reset HEAD~

Si rien n'est spécifié après git reset, par défaut il exécutera un git reset --mixed HEAD~.

Restauration dépôt

git reset --soft <reference-commit>

Permet juste de se placer sur un commit spécifique afin de voir le code à un instant donné ou créer une branche partant d'un ancien commit. Il ne supprime aucun fichier, aucun commit, et ne crée pas de HEAD détaché.

Le HEAD, est un pointeur, une référence sur notre position actuelle dans notre répertoire de travail Git. C’est un peu comme notre ombre : elle nous suit où qu’on aille ! Par défaut, HEAD pointe sur la branche courante, master, et peut être déplacé vers une autre branche ou un autre commit.

Revenir à une version antérieure "Revert Git"

Revert Git : revenir à une version antérieure de votre travail en annulant un commit.

La façon la plus rapide

git revert HEAD

Permet d'effacer un premier commit que nous allons finalement ne plus vouloir. Une fois, votre commit "annulé", vous allez pouvoir enlever votre fichier, et réaliser de nouveau votre commit.

Dans la majorité des cas la première chose à faire pour revenir à une version antérieure est d'abord de repérer cette version. La commande git log liste les différents commit (enregistrements) effectués. La chaîne de caractères situé à côté du mot commit permet d'identifier l'enregistrement. Elle sera utilisée dans toutes les commandes nécessitant un numéro d'enregistrement :

git log

qui affichera le numéro a prendre:

commit 3u38t0qn00p1sr1o8012r16kp2nsxcmul1w426w5
Author: Moi
Date: Mon Aug 1 10:00:00 2016 -0400

La démarche est ensuite différente selon votre situation. Elle dépend du travail que vous souhaitez effectuer à partir de cette version antérieure mais aussi des commits effectués depuis.

Si vous souhaitez simplement visualiser ou copier des lignes de code sans apporter aucune modification: il faut utiliser la commande git checkout en spécifiant le numéro du commit. Le répertoire de travail sera alors mis à jour pour correspondre à la version spécifiée :

git checkout 3u38t0qn00p1sr1o8012r16kp2nsxcmul1w426w5

Il est possible de créer une nouvelle branche à partir de cette version grâce à la commande git checkout :

git checkout -b old-state 3u38t0qn00p1sr1o8012r16kp2nsxcmul1w426w5

Pour revenir à la version actuelle de votre répertoire de travail, il faudra refaire un check-out.

Il est possible de revenir en arrière et de supprimer toutes les modifications qui ont été enregistrées depuis la révision mais la commande ne sera pas la même si vous ayez publié les commits ou non.

- Si vos commits n'ont pas été publiés, il suffit de revenir à la version antérieure du répertoire de travail grâce à la commande git reset :

git reset --hard 3u38t0qn00p1sr1o8012r16kp2nsxcmul1w426w5

- Si vous possédez des modifications non enregistrées dans votre répertoire de travail et que vous souhaitez les conserver, il faut exécuter en plus la commande get stash.

git stash #sauvegarde les modifications
git reset --hard 3u38t0qn00p1sr1o8012r16kp2nsxcmul1w426w5 #remet à zéro le répertoire de travail par rapport à la révision spécifiée
git stash pop #applique les modifications sauvegardées

- Si un fichier est concerné à la fois par les modifications en cours et le retour à la version antérieure du répertoire de travail, il y aura un conflit à résoudre.

- Si les commits ont été publiés, il est possible de créer un patch qui correspondra aux modifications à effectuer pour revenir en arrière, puis enregistrer les modifications avec un nouveau commit :

commande pour créer le patch qui applique la révision demandée au répertoire de travail

git revert 3u38t0qn00p1sr1o8012r16kp2nsxcmul1w426w5

il est également possible d'utiliser la commande en donnant un nombre d'enregistrements que l'on souhaite annuler (4 dans cet exemple)

git revert HEAD~4..HEAD

Vous pouvez ensuite sauvegarder votre travail. Pensez à bien spécifier ce que vous avez fait dans le message d'enregistrement

git commit

Connecter le repository local à celui de GitHub

git remote add origin <github-repository-url>

Publier les changements sur GitHub

git push origin <nom-branche>

Récupérer la dernière version du repository de GitHub

git clone <github-repository-url>

Récupérer les changements effectués

(utile quand plusieurs personnes développent en même temps)

git pull origin <nom-branche>

Importer modifications du dépôt distant sans les fusionner aux modifications locales

Git fetch

Contrairement à Git pull, va aller chercher les modifications sur le dépôt distant mais ne va pas les fusionner avec nos modifications locales. Git isole le contenu récupéré en tant que contenu local existant, cela n'a absolument aucun effet sur votre travail de développement local. La commande Git fetch va récupérer toutes les données des commits effectués sur la branche courante qui n'existent pas encore dans votre version en local. Ces données seront stockées dans le répertoire de travail local, mais ne seront pas fusionnées avec votre branche locale. Si vous souhaitez fusionner ces données pour que votre branche soit à jour, vous devez utiliser ensuite la commande Git merge.

Propreté et la cohérence de l'historique d'un projet

Le rebase permet de garder un historique plus clair et plus compréhensible.
Rebaser est une méthode courante pour intégrer les changements en amont dans votre répertoire local. L'intégration des changements en amont avec Git merge génère un commit de merge superflu dès que vous voulez voir comment le projet a évolué.

Attention ! Vous ne devez jamais rebaser des commits pushés sur le dépôt public ! Cela remplacerait les anciens commits du dépôt public, et cela  serait comme si votre historique avait brusquement disparu !

La commande git rebase standard appliquera les commits à votre branche courante puis à la pointe de la branche transférée.

Réécrivez l’historique avec l’interactif Rebase de Git

Exécuter git rebase avec l'option -i démarre une session de rebasage interactive. Cette fonctionnalité permet de déplacer les commits un à un en ayant la possibilité de les modifier. Vous avez donc la possibilité de supprimer certains commits ou de les modifier. Cette action ouvre un éditeur dans lequel vous pouvez entrer des commandes pour chaque commit à rebaser.

git rebase -i

Voici les commandes possibles :

# Commandes :
# p, pick = utilisez le commit
# r, reword = utilisez le commit, mais éditez le message de commit
# e, edit = utilisez le commit, mais arrêtez-vous pour apporter des changements
# s, squash = utilisez le commit, mais intégrez-le au commit précédent
# f, fixup = commande similaire à "squash", mais qui permet d'annuler le message de log de ce commit
# x, exec = exécutez la commande (le reste de la ligne) à l'aide de Shell 
# d, drop = supprimez le commit

Le rebasage interactif vous donne donc un contrôle complet sur l'historique de votre projet. Il sert principalement à nettoyer son historique. Il est beaucoup apprécié des développeurs qui aiment nettoyer leurs historiques avant de pousser sur le dépôt distant.

Le rebasage interactif permet ainsi de maintenir la propreté et la cohérence de l'historique d'un projet.

Rebase interactif : Modifiez l'ordre des commits

Modifier l'ordre des commits peut être utile lors d'un nettoyage avant un push sur le serveur distant. Le rebase interactif permet de le faire.

Le rebase interactif vous ouvre une fenêtre pour chaque commit à rebaser. Pour chacun de ces commits, vous allez devoir choisir une option dans la liste des commandes que nous avons vues.

# Commandes :
# p, pick = utilisez le commit
# r, reword = utilisez le commit, mais éditez le message de commit
# e, edit = utilisez le commit, mais arrêtez-vous pour apporter des changements
# s, squash = utilisez le commit, mais intégrez-le au commit précédent
# f, fixup = commande similaire à "squash", mais qui permet d'annuler le message de log de ce commit
# x, exec = exécutez la commande (le reste de la ligne) à l'aide de Shell 
# d, drop = supprimez le commit

Le petit truc à savoir, c'est que le rebase interactif va créer votre historique dans l'ordre où vous allez agir sur les commits !

Par exemple, vous avez trois commits ; on va faire simple, ils s’appelleront commit1, commit2 et commit3. Vous décidez de mettre le commit2 avant le commit1 et que vous vouliez supprimer le commit3. Faire un rebase interactif sur nos trois derniers commits :

$ git rebase -i HEAD~3

Puis vous utiliserez la commande Pick pour indiquer à Git dans quel ordre vous les voulez, et la commande Drop pour la suppression du commit3.

drop 58gfbg56 commit3
pick 14hg58g1 commit2
pick 25frgf83 commit1

N'oubliez pas que l'on appelle toujours les commits par leurs SHA-1.

Rebase interactif : Modifiez les messages de validation

La commande Git rebase interactif permet aussi de modifier les messages de commit. Imaginons que nous voulions agir sur le dernier commit.

git rebase -i HEAD^

Pour modifier ensuite son message de validation, nous allons utiliser la commande Edit.

edit 54dfiosd

Vous allez devoir sauvegarder et quitter l'éditeur. Vous aurez alors une ligne de commande vous indiquant :

$ git rebase -i HEAD^
Stopped at 54dfiosd... updated the gemspec to hopefully work better
You can amend the commit now, with

git commit --amend

Once you’re satisfied with your changes, run

git rebase --continue

Vous devrez alors faire :

git commit --amend

Puis modifier votre message de commit et enfin valider en faisant :

$ git rebase --continue

Le rebase est très pratique pour modifier vos branches, mais il est aussi très utile pour les nettoyer !

Comment utiliser Rebase pour nettoyer votre branche ? Nous avons vu dans le chapitre précédent que Git rebase était très utile pour modifier l'ordre des commits, et modifier les messages de commit. Nous allons voir maintenant que Git rebase est un véritable couteau suisse de Git. Il va nous permettre de modifier des commits intermédiaires avant d'envoyer sur le dépôt à distance.

Il est important de toujours nettoyer son historique avant d'envoyer sur le dépôt à distance !

Rebase interactif : Nettoyer vos branches

Le rebasage interactif permet ainsi de maintenir la propreté et la cohérence de l'historique d'un projet.

Rappelons les commandes du rebase interactif :

# Commandes :
# p, pick = utilisez le commit
# r, reword = utilisez le commit, mais éditez le message de commit
# e, edit = utilisez le commit, mais arrêtez-vous pour apporter des changements
# s, squash = utilisez le commit, mais intégrez-le au commit précédent
# f, fixup = commande similaire à "squash", mais qui permet d'annuler le message de log de ce commit
# x, exec = exécutez la commande (le reste de la ligne) à l'aide de Shell 
# d, drop = supprimez le commit

Sélectionnons les deux derniers commits :

$ git rebase -i HEAD~2

Puis supprimons-les avec la commande Drop :

drop 58gkbg56 commit52
drop 899hbg78 commit53

Vos commits ont été supprimés et votre branche est désormais propre.

Rebase interactif: Squash ? Débarrassez-vous des commits à tout va !

Squash est une de ces super fonctionnalités du rebase interactif ! Un squash est un regroupement de plusieurs commits. Le but est de les fusionner en un seul pour avoir un historique Git plus propre. Il est notamment conseillé de le faire dans le cadre des envois sur le dépôt à distance, pour simplifier la relecture des modifications effectuées.

Non seulement Squash va fusionner vos modifications, mais il va aussi fusionner vos messages de commit !

Mais alors, comment l'utiliser ? il s'utilise comme le reste des commandes du rebase interactif. On va aller sélectionner tous les commits nous intéressant, et on va leur appliquer la commande Squash !

git rebase -i HEAD~3

On leur applique la commande Squash :

pick 57dcsd58 Création du formulaire
squash 58gkbg56 Design Formulaire
squash 899hbg78 Correction du formulaire

Concrètement, on dit à GIT de se baser sur le premier commit et on lui applique tous les suivants pour n’en faire qu’un seul.

Lorsque l’on valide le squash, Git va réappliquer les commits dans le même ordre dans lequel ils ont été configurés juste avant. On met alors un message de commit qui concerne le regroupement de nos commits.

Supprimez les branches non suivies

Maintenant que vous savez comment nettoyer vos branches à l'aide Git rebase, il est parfois très utile de tout simplement les supprimer.

Prenons l'exemple des arbres, il y a des branches qui sont harmonieuses et que les paysagistes vont laisser, et d'autres qui ne sont pas jolies ou qui n'ont pas d'utilité et que l'on va tailler ! :)

Avec Git, on supprime les branches non suivies avec :

git branch -d brancheTest

Trouvez l’origine d’un bug avec Git bisect

On ne va pas se mentir, lorsque l'on développe, on perd beaucoup de temps à déboguer notre application. :euh: C'est toujours long et fastidieux de retrouver ce qui a pu provoquer le bug en question ! Git se propose de réduire ce fameux temps de recherche grâce à Git bisect.

Le principe est plutôt simple. Vous indiquez à Git que vous cherchez un bug, il se déplace de commit en commit, vous testez la version et vous lui dites si le bug est présent dans le commit courant ou pas.

Le but est de retrouver le premier commit où le bug est apparu. Grâce à cela, vous saurez que l'une des modifications faites dans ce commit a causé le bug. ;) Il faut bien entendu avoir réalisé des commits réguliers. :) Si vous n'avez pas fait de commit depuis deux semaines, passez votre chemin ! Il faudra chercher le bug à la main.

D'où l'intérêt de tout petits commits : plus vos commits seront petits, plus l'utilisation de git bisect sera utile, puisqu'elle permettra de localiser plus précisément où est situé le bug dans votre code. :D

On commence par la commande start :

git bisect start [bad] [good]

Au lieu de bad, vous devrez mettre le hash d'un commit où le bug est présent. À la place de good, vous devrez mettre le hash d'un commit où le bug n'était pas présent !

Git va alors naviguer dans chacun des commits entre les deux, dans le but de trouver le premier commit où le bug est apparu.

Git va se déplacer sur chaque commit et vous allez devoir, pour chacun de ces commits, lui indiquer si le commit est good ou bad. :)

Si le commit ne présente pas le bug :

git bisect good

Si le commit présente le bug :

git bisect bad

Une fois chaque commit vérifié, Git va vous indiquer le commit qui a provoqué le bug. Il va l'indiquer de cette manière :

fvsd54g5s5d4g5f34g5dfg47df578q9qdff6 is first bad commit
commit fvsd54g5s5d4g5f34g5dfg47df578q9qdff6
Author: Moi <Moi@example.com>
Date: Tue mar 27 16:28:38 2019 -0800

Add fonctionnality AB

Il ne vous reste plus qu'a trouver dans vos modifications, la modification qui a engendré le problème.

Définir les sous-arborescences et les sous-modules

Les sous-modules reposent sur l'imbrication de dépôts : vous avez des dépôts… dans des dépôts.
Concernant les sous-arborescences, il n'y a pas de dépôts imbriqués : on n'a qu'un dépôt, le conteneur. Les sous-arborescences sont plutôt un concept.

- Commençons par les sous-modules. N'avez-vous jamais eu envie d'inclure un projet tiers au sein du projet sur lequel vous étiez en train de travailler ? Je ne parle pas d'une simple dépendance tierce, mais d'un module ou d'une bibliothèque que vous développez simultanément. Admettons que vous ayez à développer deux projets totalement distincts, mais qui vont à un moment devoir se retrouver. C'est un cas typique d'utilisation des sous-modules Git, car ils vont vous permettre d'inclure un autre dépôt Git au sein de votre projet actuel. Il vous sera alors possible de gérer vos commits séparément pour chacun des dépôts.

git submodule add https://github.com/etudiantOC/ProjetSubModule dossier/destination

Cette commande va ajouter à notre dépôt courant le projet ProjetSubModule, comme sous-module dans le dossier Dossier/Destination. Vous noterez également qu'au travers de cette opération, Git a ajouté un nouveau fichier de configuration nommé .gitmodules contenant la description des sous-modules utilisés par le projet.

- Maintenant, voyons la différence avec les sous-arborescences. Si vous avez déjà développé des projets, vous avez sûrement déjà dû vous dire qu'il vous serait utile de garder une fonctionnalité pour la réutiliser dans d'autres projets. Il pourrait être très facile de juste copier-coller les fichiers, et de les remettre plus tard dans les autres projets. Cependant, vous perdriez tout l'historique sur ces fonctionnalités. Heureusement, il existe les sous-arborescences Git !

Git subtree va vous permettre de créer un nouvel arbre de commits pour un sous-dossier de votre dépôt Git. Autrement dit, Git subtree régénère l’historique d’un dossier.

git subtree push -P monRépertoire git@mon-serveur-git:group/projet.git master

Votre répertoire va être pushé sur votre nouveau dépôt distant sur la branche master.

Travaillez-en-equipe-en-utilisant-un-workflow

https://openclassrooms.com/fr/courses/5641721-utilisez-git-et-github-pour-vos-projets-de-developpement/6113111-travaillez-en-equipe-en-utilisant-un-workflow

Memo GIT ligne de commande