Introduction à Git

Table des matières

Préface
1. Configurer git
.... 1.1 Fichiers de configuration
.... 1.2 Paramètres par défaut
.... 1.3 Alias
2. Les bases de git
.... 2.1 Création d'un référentiel
.... 2.2 État du fichier
.... 2.3 Travailler avec l'index
.... 2.4 Travailler avec des validations
.... 2.5 Voir l'historique
.... 2.6 Travailler avec un référentiel distant
3. Ramification dans git
.... 3.1 Opérations de base
.... 3.2 Fusion de succursales
.... 3.3 Rerere
4. Pointeurs en git
.... 4.1 Déplacement des pointeurs
5. Lecture recommandée

Préface

Git est le système de contrôle de version distribué le plus populaire. [1] [2]

Le but principal de Git est de sauvegarder des instantanés d'amélioration successive des conditions de votre projet (Pro git, 2019).

Cet article est destiné à ceux qui ont au moins des connaissances et des compétences de base pour travailler avec git et qui souhaitent approfondir leurs connaissances.

Seuls les aspects techniques de git sont considérés ici, pour une immersion plus détaillée dans la philosophie de git et son implémentation interne, je vous conseille de lire plusieurs livres utiles (voir Lecture recommandée ).

1. Configurer git

Avant de commencer à travailler avec git, vous devez le configurer vous-même!

1.1 Fichiers de configuration

• / etc / gitconfig - Paramètres généraux pour tous les utilisateurs et référentiels
• ~ / .gitconfig ou ~ / .config / git / config - Paramètres utilisateur spécifiques
• .git / config - Paramètres pour un référentiel spécifique

Il y a une équipe spéciale

git config [<>] 

ce qui vous permettra de changer le comportement standard de git, si nécessaire, mais vous pouvez éditer les fichiers de configuration manuellement (je pense que c'est plus rapide).

Selon le paramètre que vous passez à la commande git config (--system, --global, --local), les paramètres seront écrits dans l'un de ces fichiers. Chacun de ces «niveaux» (système, global, local) redéfinit les valeurs du niveau précédent!

Pour voir dans quel fichier quels paramètres sont installés, utilisez git config --list --show-origin.

Ignorer les fichiers
Dans git, vous décidez quels fichiers iront dans quel commit, mais vous voudrez peut-être que certains fichiers ne soient jamais dans l'index et dans le commit, et n'apparaissent même pas dans la liste non suivie. Pour ce faire, vous pouvez créer un fichier spécial (.gitignore) dans votre référentiel et y écrire le modèle de fichiers ignorés. Si vous ne souhaitez pas créer un tel fichier dans chaque référentiel, vous pouvez le définir globalement à l'aide de core.excludesfile (voir Paramètres utiles ). Vous pouvez également télécharger le fichier .gitignore terminé pour le langage de programmation sur lequel vous travaillez.
Pour personnaliser .gitignore, utilisez les expressions régulières bash .

1.2 Paramètres par défaut

Il y a un tas de paramètres git pour le serveur et le client, seuls les paramètres client de base seront considérés ici.

Utiliser

 git config name value 

où nom est le nom du paramètre et valeur est sa valeur afin de définir les paramètres.
Un exemple:

 git config --global core.editor nano 

va installer l'éditeur par défaut nano.

Vous pouvez afficher la valeur d'un paramètre existant avec git config --get [nom] où nom est le paramètre dont vous souhaitez obtenir la valeur.

Paramètres utiles:

• user.name - Le nom qui sera utilisé lors de la création de la validation
• user.email - E-mail à utiliser lors de la création du commit
• core.excludesfile - Un fichier dont le modèle sera utilisé pour ignorer des fichiers spécifiques globalement
• core.editor - L'éditeur par défaut
• commit.template - Le fichier dont le contenu sera utilisé pour le message de validation par défaut (voir Utilisation des validations).
• help.autocorrect - Lorsqu'il est défini sur 1, git exécutera des commandes incorrectement écrites.
• credential.helper [mode] - Définit le mode de stockage des informations d'identification. [cache] - les informations d'identification sont enregistrées pendant une certaine période, les mots de passe ne sont pas enregistrés (- timeout [secondes] le nombre de secondes après lesquelles les données sont supprimées, la valeur par défaut est de 15 minutes). [store] - les informations d'identification sont stockées pendant une durée illimitée en clair (--file [fichier] indique le chemin pour stocker les données, par défaut ~ / .git-credentials).

1.3 Alias

Si vous ne souhaitez pas imprimer chaque commande pour Git dans son intégralité, vous pouvez facilement configurer des alias. Pour créer un alias, utilisez:

 git config alias.SHORT_NAME COMMAND 

où SHORT_NAME est le nom à abréger et COMMANDER la ou les commandes à abréger. Un exemple:

 git config --global alias.last 'log -1 HEAD' 

après avoir exécuté cette commande, vous pouvez afficher des informations sur le dernier commit sur la branche actuelle en exécutant git last.

Je vous conseille d'utiliser les abréviations suivantes (vous pouvez également définir l'une des vôtres):

• st = statut
• ch = caisse
• br = branche
• mg = fusion
• cm = commit
• reb = rebase
• lg = "git log --pretty = format: '% h -% ar:% s'”

Pour afficher les paramètres de configuration, utilisez: git config --list.

2. Les bases de git

Seuls les paramètres obligatoires et utiles (à mon avis) sont répertoriés ici, car répertorier tout est inapproprié. Pour ce faire, utilisez la commande git -help ou --help, où command est le nom de la commande pour l'aide que vous souhaitez recevoir.

2.1 Création d'un référentiel

• git init [<options>] - Crée un référentiel git et un répertoire .git dans le répertoire courant (ou dans le répertoire spécifié après --separate-git-dir <racine_git>, auquel cas le répertoire .git sera à un autre endroit);
• git clone [<options>] [-] <repository> [<folder>] [-o, --origin <name>] [-b, --branch <branch>] [--single-branch] [- -no-tags] [--separate-git-dir <répertoire-git>] [-c, --config <clé = valeur>] - Cloner les référentiels avec le nom d'origine (ou celui que vous spécifiez -o <nom> ), se trouvant sur la branche vers laquelle HEAD pointe (ou celle que vous spécifiez -b <branch>). Vous pouvez également cloner uniquement la branche HEAD nécessaire (ou celle spécifiée dans -b <branch>) en spécifiant --single-branch. Par défaut, toutes les balises sont clonées, mais en spécifiant --no-tags, vous ne pouvez pas les cloner. Une fois la commande exécutée, le répertoire .git est créé dans le répertoire actuel (ou dans le répertoire spécifié après --separate-git-dir <racine_git>, auquel cas le répertoire .git sera situé ailleurs);

2.2 État du fichier

Pour afficher l'état des fichiers dans votre référentiel, utilisez:

 git status [<>] 

Cette commande peut vous montrer: quelle branche vous êtes actuellement et l'état de tous les fichiers. Aucune option n'est requise, seuls les -s peuvent être distingués des options utiles, qui donneront une brève idée de l'état des fichiers.

Cycle de vie des fichiers
Comme vous pouvez le voir sur l'image, les fichiers peuvent être non suivis et suivis. Les fichiers surveillés peuvent être dans 3 états: non modifiés (non modifiés), modifiés (modifiés), préparés (par étapes).
Si vous ajoutez (à l'aide de git add) un fichier «non surveillé», il passe alors à l'état «Préparé».
Si vous changez le fichier à l'état «Non modifié», il passe à l'état «Modifié». Si vous enregistrez le fichier modifié (c'est-à-dire à l'état "Modifié"), il passe à l'état "Préparé". Si vous validez un fichier (c'est-à-dire à l'état "Préparé"), il passe à l'état "Non modifié".
Si les versions du fichier dans HEAD et le répertoire de travail sont différentes, alors le fichier sera dans les états "Modifié", sinon (si la version dans HEAD et le répertoire de travail sont les mêmes "), le fichier sera dans les états" Non modifié ".
Si la version du fichier dans HEAD diffère du répertoire de travail, mais ne diffère pas de la version dans l'index, le fichier sera à l'état «Préparé».

Ce cycle peut être représenté comme suit:
Non modifié -> Modifié -> Étagé -> Non modifié
Autrement dit, vous modifiez le fichier, l'enregistrez dans l'index et effectuez une validation, puis recommencez.

2.3 Travailler avec l'index

J'espère que vous comprenez à quoi ressemble le cycle de vie du référentiel git. Voyons maintenant comment gérer l'index et les fichiers dans votre référentiel git.

Un index est un endroit intermédiaire entre votre dernier commit et le suivant. Vous pouvez ajouter ou supprimer des fichiers de l'index. Lorsque vous validez, il obtient les données de l'index et non de l'espace de travail.

Pour afficher l'index, utilisez git status.

Pour ajouter des fichiers à l'index, utilisez

 git add [<>] 

Options de commande git add utiles:

• -f, --force - ajoute également des fichiers ignorés
• -u, --update - met à jour les fichiers suivis

Pour supprimer des fichiers de l'index, vous pouvez utiliser 2 commandes git reset et git restore.
git-restore - restaure les fichiers d'arborescence de travail.
git-reset - réinitialise le HEAD actuel à l'état spécifié.
En fait, vous pouvez réaliser la même chose avec les deux commandes.

Pour supprimer certains fichiers de l'index, utilisez:

 git restore --staged <file> 

De cette façon, vous restaurerez votre index (ou plutôt, supprimerez des fichiers spécifiques de l'index), comme si git add n'avait pas été exécuté pour eux depuis le dernier commit. Avec cette commande, vous pouvez restaurer le répertoire de travail afin qu'il semble qu'aucune modification n'ait été effectuée après la validation. Mais cette commande a un comportement un peu étrange - si vous avez ajouté une nouvelle version de votre fichier à l'index, vous ne pouvez pas modifier votre répertoire de travail tant que l'index n'est pas différent de HEAD. Par conséquent, vous devez d'abord restaurer votre index, puis uniquement le répertoire de travail. Malheureusement, il n'est pas possible de le faire avec une seule commande, car lors du passage des deux arguments (git restore -SW), rien ne se passe. Et tout de même, lorsque -W est passé, rien ne se passera si le fichier dans l'index et HEAD sont différents. Probablement, ils l'ont fait pour la protection afin que vous ne changiez pas accidentellement votre répertoire de travail. Mais dans ce cas, pourquoi l'argument -W est-il passé par défaut? En général, je ne comprends pas pourquoi cela a été fait et pourquoi cette commande a été ajoutée. Pour moi, réinitialiser les copies de cette tâche est beaucoup mieux, et il a également des fonctionnalités plus riches car il peut déplacer l'index et le répertoire de travail non seulement vers le dernier commit, mais aussi vers n'importe quel autre.

Mais les développeurs eux-mêmes recommandent d'utiliser git restore -S pour réinitialiser l'index. Au lieu de git, réinitialisez HEAD.

En utilisant git status, vous pouvez voir quels fichiers ont changé, mais si vous voulez également savoir ce qui a changé exactement dans les fichiers, utilisez la commande:

 git diff [<options>] 

ainsi, en exécutant la commande sans arguments, vous pouvez comparer votre index avec le répertoire de travail. Si vous avez déjà ajouté des fichiers à l'index, utilisez git diff --cached pour voir les différences entre le dernier commit (ou celui que vous spécifiez) et le répertoire de travail. Vous pouvez également voir les différences entre deux validations ou branches en les passant comme argument. Exemple: git diff 00656c 3d5119 montre les différences entre commit 00656c et 3d5119.

2.4 Travailler avec des validations

Maintenant que votre index est dans le bon état, il est temps de valider vos modifications. N'oubliez pas que tous les fichiers pour lesquels vous n'avez pas exécuté git add après la modification ne sont pas inclus dans ce commit. En fait, il y aura des fichiers, mais seulement leur ancienne version (le cas échéant).

Pour valider vos modifications, utilisez:

 git commit [<>] 

Options utiles pour la commande git commit:

• -F, --file [fichier] - Ecrit un message de validation à partir du fichier spécifié
• --author [author] - Remplacer l'auteur du commit
• --date [date] - Modifier la date de validation
• -m, --mesage [message] - Validation du message
• -a, --all - Valide toutes les modifications apportées aux fichiers
• -i, --include [files ...] - Ajoute les fichiers spécifiés à l'index pour le prochain commit
• -o, --only [files ...] - Valide uniquement les fichiers spécifiés
• --amend - Remplace le commit précédent

Vous pouvez définir un message de validation par défaut à l'aide de commit.template. Cette directive du fichier de configuration est responsable du fichier dont le contenu sera utilisé pour la validation par défaut. Exemple: git config --global commit.template ~ / .gitmessage.txt.

Vous pouvez également modifier, supprimer, fusionner n'importe quel commit.
Comme vous l'avez peut-être remarqué, vous pouvez rapidement remplacer le dernier commit avec git commit --amend.
Pour modifier le commit dans votre histoire, utilisez

 git rebase -i <commit> 

où commit est le premier commit de votre chaîne à partir duquel vous souhaitez modifier quoi que ce soit.

Après avoir exécuté git rebase -i dans le menu interactif, sélectionnez ce que vous voulez faire.

• pick <commit> = utilisez commit
• reformuler <commit> = utiliser commit, mais changer le message de commit
• edit <commit> = utilisez commit, mais arrêtez pour corriger
• squash <commit> = utilisez commit, mais fusionnez avec le commit précédent
• fixup <commit> = comme "squash", mais ignorez le message de commit
• exec <command> = exécute la commande (reste de la ligne) en utilisant le shell
• break = arrêter ici (continuer avec "git rebase --continue")
• drop <commit> = supprimer le commit
• label <label> = donner un nom à la HEAD actuelle
• reset <label> = réinitialiser HEAD sur l'étiquette spécifiée

Pour changer le message d'un commit spécifique.
Vous devez modifier le choix à modifier sur le commit que vous souhaitez modifier.
Exemple: vous souhaitez modifier le message de validation 750f5ae.

choisir 2748cb4 premier commit
modifier le second commit 750f5ae
choisir 716eb99 troisième commit

Après avoir enregistré le script, vous reviendrez à la ligne de commande et git vous dira quoi faire ensuite:

Arrêté à 750f5ae ... deuxième commit
Vous pouvez modifier le commit maintenant, avec

git commit --amend

Une fois que vous êtes satisfait de vos modifications, exécutez

git rebase --continue

Comme indiqué ci-dessus, vous devez exécuter git commit --amend afin de changer le message de validation. Exécutez ensuite git rebase --continue. Si vous avez sélectionné plusieurs validations pour changer le nom, ces opérations devront être effectuées sur chaque validation.

Pour supprimer un commit
Vous devez supprimer la ligne avec le commit.
Exemple: vous souhaitez supprimer le commit 750f5ae
Vous devez changer le script à partir de ceci:
choisir 2748cb4 troisième commit
choisir 750f5ae deuxième commit
choisissez 716eb99 premier commit
à ce sujet:
choisir 2748cb4 premier commit
choisir 716eb99 troisième commit

Pour fusionner les validations
Vous devez modifier le choix pour écraser les validations que vous souhaitez fusionner.
Exemple: vous souhaitez combiner les validations 750f5ae et 716eb99.
Vous devez changer le script à partir de ceci:
choisir 2748cb4 troisième commit
choisir 750f5ae deuxième commit
choisissez 716eb99 premier commit
Sur tel
choisir 2748cb4 troisième commit
squash 750f5ae second commit
squash 716eb99 premier commit

Notez que dans le script interactif, les validations sont affichées dans l'ordre inverse de celles dans git log. En utilisant squash, vous combinez le commit 750f5ae avec 716eb99 et le commit 750f5ae avec 2748cb4. Par conséquent, obtenir un commit contenant des modifications aux trois.

2.5 Afficher l'historique

Utilisation de la commande

 git log [<>] [<->] 

Vous pouvez afficher l'historique des validations de votre référentiel. Il existe également des tonnes d'options pour trier et rechercher un commit spécifique.

Options de commande git log utiles:

• -p - Affiche la différence pour chaque commit.
• --stat - Affiche les statistiques des fichiers modifiés pour chaque commit.
• --graph - Affiche un graphique ASCII avec les branches et l'historique des fusions.

Vous pouvez également trier les validations par heure, quantité, etc.

• - (n) Affiche uniquement les n derniers validations.
• --since, --after - Affiche les validations effectuées après la date spécifiée.
• --until, --before - Affiche les validations effectuées avant la date spécifiée.
• --author - Affiche uniquement les validations dans lesquelles l'entrée d'auteur correspond à la chaîne spécifiée.
• --committer - Affiche uniquement les validations dans lesquelles l'entrée de validation correspond à la chaîne spécifiée.
• --grep - Affiche uniquement les validations dont le message contient la chaîne spécifiée.
• -S - Affiche uniquement les validations dans lesquelles une modification du code a entraîné l'ajout ou la suppression de la ligne spécifiée.

Voici quelques exemples:
git log --since = 3.weeks - Afficher les validations au cours des 2 dernières semaines
git log --since = "2019-01-14" - Afficher les commits effectués le 2019-01-14
git log --since = "il y a 2 ans 1 jour" - Affiche les commits effectués il y a 2 ans et un jour.

Vous pouvez également personnaliser le format de sortie de vos validations avec

 git log --format:["format"] 

Options de formatage pour git log --format.

• % H - Valider le hachage
• % h - Hachage de validation raccourci
• % T - Hachage d'arbre
• % t - Hachage d'arbre raccourci
• % P - Hachage parent
• % p - Hachage parent abrégé
• % an - Nom de l'auteur -% ae - Courriel de l'auteur
• % ad - Date de l'auteur (le format de la date peut être défini avec l'option --date = option)
• % ar - Date relative de l'auteur
• % cn - Nom du committer
• % ce - Courriel du fournisseur
• % cd - Date de validation
• % cr - Date de validation relative
• % s - Contenu

Un exemple:

 git log --pretty=format:"%h - %ar : %s" 

affichera une liste de validations consistant en un hachage temporel et un message de validation.

2.6 Travailler avec un référentiel distant

Puisque git est une devise forte distribuée, vous pouvez travailler non seulement avec des référentiels locaux mais aussi avec des référentiels externes.

Les référentiels distants sont des versions de votre projet stockées sur un serveur externe.

Pour travailler avec des référentiels externes, utilisez:

 git remote [<options>] 

Si vous avez cloné les référentiels via l'URL http, vous disposez déjà d'un lien vers l'externe. Sinon, vous pouvez l'ajouter avec

 git remote add [<options>] <name> <adres> 

Vous pouvez immédiatement extraire les branches externes en utilisant -f, --fetch (vous obtenez les noms et l'état des branches du référentiel externe). Vous pouvez uniquement configurer des référentiels pour envoyer ou recevoir des données en utilisant --mirror [= (push | fetch)]. Pour obtenir des balises, spécifiez --tags.

Pour afficher les référentiels externes connectés, utilisez git remote sans arguments ou git remote -v pour afficher les adresses pour envoyer et recevoir des données du référentiel.

Pour suivre les branches, utilisez git branch -u <rep / br> où rep est le nom du référentiel, br est le nom de la branche externe et branch est le nom de la branche locale. Ou git branch --set-upstream local_br origin / br afin d'indiquer quelle branche locale surveillera la branche externe.

Lorsque votre branche garde une trace d'une externe, vous pouvez savoir quelle branche (locale ou externe) est derrière ou devant et par combien de commits. Par exemple, si après une validation, vous n'avez pas effectué de git push, votre branche sera en avance sur la validation externe par 1. Pour en savoir plus, exécutez git branch -vv, mais commencez par git fetch [nom-distant] (--all pour obtenir les mises à jour de tous les référentiels) pour obtenir les dernières données d'un référentiel externe. Pour annuler le suivi des branches, utilisez git branch --unset-upstream [<local_branch>].

Pour télécharger des données à partir d'un référentiel externe, utilisez git pull [rep] [branch]. Si vos branches effectuent un suivi externe, vous ne pouvez pas les spécifier lors de l'exécution de git pull. Par défaut, vous recevrez des données de toutes les branches surveillées.

Pour télécharger des branches dans une nouvelle branche, utilisez git checkout -b <new_branch_name> <rep / branch>.

Pour envoyer des données au serveur, utilisez

 git push [<rep>] [<br>] 

où rep est le nom du référentiel externe et br est la branche locale que vous souhaitez envoyer. Vous pouvez également utiliser cette entrée git push origin master: dev. Ainsi, vous téléchargez votre branche principale locale vers l'origine (mais là, elle s'appellera dev). Vous ne pourrez pas envoyer de données à un référentiel externe si vous n'êtes pas autorisé à le faire. De plus, vous ne pourrez pas envoyer de données à une branche externe si elles sont en avance sur la vôtre (en général, vous pouvez envoyer en utilisant -f, --forse dans ce cas, vous réécrirez l'historique sur le référentiel externe). Vous pouvez omettre le nom de la succursale si votre succursale suit l'extérieur.

Pour supprimer des branches externes, utilisez

 git push origin --delete branch_name 

Pour des informations détaillées sur le référentiel externe (adresses d'envoi et de réception, comme indiqué par HEAD, branches externes, branches locales configurées pour git pull et liens locaux configurés pour git push)

 git remote show <remote_name> 

Pour renommer le nom du référentiel externe, utilisez

 git remote rename <last_name> <new_name> 

Pour supprimer des liens vers un référentiel externe, utilisez

 git remote rm <name> 

3. Ramification dans git

Le branchement est un outil puissant et l'une des principales fonctionnalités de git car il vous permet de créer rapidement et de basculer entre les différentes branches de votre référentiel. Le concept principal de ramification est que vous pouvez décoller de la ligne principale de développement et continuer à travailler indépendamment d'elle, sans interférer avec la ligne principale. Une branche pointe toujours vers le dernier commit et HEAD pointe vers la branche courante (voir Pointeurs dans git ).

3.1 Opérations de base

Pour créer une branche, utilisez

 git branch <branch_name> [<start_commit>] 

Ici nom_branche est le nom de la nouvelle branche, et start_commit est le commit vers lequel la branche va pointer (c'est-à-dire le dernier commit dedans). Par défaut, la branche sera sur le dernier commit de la branche parent.

Options de branche Git:

• -r | -a [--merged | --no-merged] — -r. -a. --merged. --no-merged.
• -l, -f <-> [<->] — -l. , -f. < >.
• -r (-d | -D) — -r. -d. ( ) -D.
• -m | -M [< >] < > — / (-m). / , -M.
• (- | -) [<->] <-> — -c. , -C.
• -v, -vv - Liste des branches avec le dernier commit sur la branche -v. Liste et statut des branches surveillées avec le dernier commit sur elles.

Voir git branch -h pour plus d'informations | - aider.

Pour passer à une branche, utilisez git checkout. Vous pouvez également créer une branche en exécutant git checkout -b <branch>.

3.2 Fusion de succursales

Pour fusionner 2 branches d'un référentiel git, utilisez git merge.

Options utiles pour la fusion git:

• --squash - Créez un commit au lieu de fusionner. Si vous avez un conflit sur les branches, après l'avoir résolu, vous aurez 2 commits ajoutés sur la branche (commit à partir de la branche fusionnée + commit de fusion), mais en spécifiant cet argument vous n'ajouterez qu'un seul commit (commit fusionné).
• --ff-only - Ne fusionne pas en cas de conflit. Laissez quelqu'un d'autre résoudre les conflits: D
• -X [stratégie] - Utilisez la stratégie de fusion sélectionnée.
• --abort - Annule la fusion.

Le processus de fusion.
Si vous n'avez pas exécuté de nouvelles validations sur la branche parent, la fusion se résume à une avance rapide, comme si vous ne créiez pas de nouvelle branche, et toutes les modifications se sont produites ici (sur la branche parent).

Si vous avez effectué des validations sur les deux branches, mais n'avez pas créé de conflit, la fusion aura lieu dans la «stratégie récursive», c'est-à-dire qu'il vous suffit de créer une validation de fusion pour appliquer les modifications (utilisez l'option --squash pour éviter de créer une validation supplémentaire) .
Si vous avez effectué des validations sur les deux branches qui ont apporté des modifications différentes à la même partie du même fichier, vous devrez résoudre le conflit et valider la validation de fusion.

Lors de la résolution du conflit, vous devez choisir la partie des modifications des deux branches que vous souhaitez quitter. Lorsque vous ouvrez un fichier en conflit, il contient les éléments suivants:
<<<<<<< HEAD
Il y aura une version du dernier commit de la branche courante
======
Il y aura une version du dernier commit de la branche fusionnée
>>>>>>> Ici le nom branches avec lesquelles nous fusionnons

Après avoir résolu le conflit, vous devez terminer la fusion en vous engageant.

Pendant un conflit, vous pouvez voir quelles différences existent dans quels fichiers.
git diff --ours - Différence avant la fusion et après
git diff --les - Différence de branche fusionnée avant la fusion et après
git diff --base - Différence avec les deux branches avant la fusion et après

Si vous ne souhaitez pas autoriser la fusion, utilisez différentes stratégies de fusion, soit en choisissant «notre» version (c'est-à-dire celle située sur la branche actuelle), soit en choisissant «leur» version située sur la branche fusionnée sans corriger le conflit. Exécutez respectivement git merge --Xours ou git merge --Xtheirs.

3.3 Rerere

Rerere - «réutiliser la résolution enregistrée» - «réutiliser les résolutions de conflit enregistrées». Le mécanisme de rerere est capable de se rappeler comment vous avez résolu une certaine partie du conflit dans le passé et de corriger automatiquement le conflit la prochaine fois qu'il se produit.

Pour activer rerere do

 git config --global rerere.enabled true 

Vous pouvez également activer rerere en créant le répertoire .git / rr-cache dans le référentiel souhaité.

Utilisez git rerere status pour voir pour quels fichiers rerere a enregistré des instantanés avant de les fusionner.

Utilisez git rerere diff pour afficher l'état actuel du conflit.

Si pendant la fusion, il est dit: 'nameFile' résolu en utilisant la résolution précédente. Rerere a donc déjà résolu le conflit en utilisant le cache.

Pour annuler la résolution automatique des conflits, utilisez git checkout --conflict = merge afin d'annuler la résolution automatique des conflits et de remettre les fichiers à l'état de conflit pour une résolution manuelle.

4. Pointeurs en git

git a des pointeurs comme la branche HEAD. En fait, tout est très simple, HEAD pointe vers la branche actuelle et la branche pointe vers le dernier commit. Mais pour comprendre, il vaut mieux imaginer que HEAD indique le dernier commit.

4.1 Déplacement des pointeurs

Le livre Pro git fournit un très bon exemple de la façon dont vous pouvez gérer votre référentiel, donc je m'en tiendrai aussi. Imaginez Git gérer le contenu de trois arbres différents. Ici, «arborescence» fait référence à un «ensemble de fichiers».
Dans ses opérations habituelles, Git gère trois arbres:

• HEAD - Instantané du dernier commit, parent du suivant
• Index - Instantané du prochain commit à venir
• Répertoire de travail - Sandbox

En fait, git fournit des outils pour manipuler les trois arbres. Ensuite, la commande git reset sera discutée, ce qui vous permet de travailler avec trois arborescences de votre référentiel.

En utilisant les différentes options de cette commande, vous pouvez:

• --soft - Réinitialiser HEAD uniquement
• --mixed - Réinitialiser la tête et l'index
• --hard - Réinitialise HEAD, index et répertoire de travail

Par réinitialiser signifie passer au commit spécifié. La valeur par défaut est --mixed.

Exemple 1. Vous avez effectué 3 validations supplémentaires, chacune apportant de petites modifications et vous souhaitez en effectuer une, vous pouvez donc utiliser git reset --soft pour déplacer le pointeur HEAD tout en laissant l'index et le répertoire de travail intact et validé. Par conséquent, votre histoire ressemblera à tous les changements survenus en un seul commit.

Exemple 2. Vous avez ajouté des fichiers supplémentaires à l'index et souhaitez les supprimer de là. Vous pouvez utiliser git reset HEAD <fichiers ...> pour cela. Ou voulez-vous que les fichiers de validation ressemblent à quelques validations. Comme je l'ai dit plus tôt, vous pouvez réinitialiser l'index à n'importe quel commit, contrairement à git restore, qui ne réinitialise que le dernier commit. Ce n'est qu'avec l'option mixte que vous pouvez appliquer une action au fichier spécifié!

Exemple 3. Vous avez commencé à travailler sur une nouvelle fonctionnalité de votre projet, mais soudainement l'employeur dit qu'elle n'est plus nécessaire et que vous êtes en colère de faire git reset --hard renvoyant votre index, vos fichiers et votre HEAD au moment où vous n'avez pas commencé à travailler fonctionnalités. Et le lendemain, on vous dit que la fonction devrait toujours être nettoyée. Mais que faire? Comment aller de l'avant, car vous avez annulé les trois arbres et vous ne pouvez plus les trouver dans l'historique à l'aide de git log. Et il y a un moyen de sortir - c'est le journal de lien git reflog. Avec cette commande, vous pouvez voir où HEAD pointait et elle se déplacera non seulement vers le bas de l'historique des validations, mais aussi vers le haut. Ce journal est local pour chaque utilisateur.

En général, je pense que vous pouvez trouver beaucoup plus d'exemples que moi. En conclusion, je peux dire qu'avec git reset vous pouvez faire de la magie ...

5.

1. Pro git — Scott Chacon
2. Git — . , ,
3. Git Essentials — F. Santacroce
4. Git: Version Control for Everyone (2013) — R. Somasundaram
5. Version Control with Git: Powerful tools and techniques for collaborative software development (2009) — J. Loeliger, M. McCullough
6. Practical Git and GitHub (2016) — D. Cruz
7. Git in Practice (2016) — M. McQuaid
8. Git Best Practices Guide (2014) — E. Pidoux
9. Learn Enough Git to Be Dangerous (2016) — M. Hartl
10. Learn Version Control with Git: A step-by-step course for the complete beginner (2014) — T. Günther
11. Git: Learn Version Control with Git: A step-by-step Ultimate beginners Guide (2017) — D. Hutten
12. Pragmatic Guide to Git (2010) — S. Travis
13. Git (2016) — .
14. A Hacker's Guide to Git (2014) — J. Wynn
15. Practical Git and GitHub (2016) — D. Cruz
16. Deploying to OpenShift(2018) — G. Dumpleton
17. Git for Teams (2015) — Emma Jane Hogbin Westby