Git - Guide rapide

Système de contrôle de version

Version Control System (VCS) est un logiciel qui aide les développeurs de logiciels à travailler ensemble et à conserver un historique complet de leur travail.

Vous trouverez ci-dessous les fonctions d'un VCS -

• Permet aux développeurs de travailler simultanément.
• Ne permet pas d'écraser les modifications de l'autre.
• Conserve un historique de chaque version.

Voici les types de VCS -

• Système de contrôle de version centralisé (CVCS).
• Système de contrôle de version distribué / décentralisé (DVCS).

Dans ce chapitre, nous nous concentrerons uniquement sur le système de contrôle de version distribué et en particulier sur Git. Git relève du système de contrôle de version distribué.

Système de contrôle de version distribué

Le système de contrôle de version centralisé (CVCS) utilise un serveur central pour stocker tous les fichiers et permet la collaboration en équipe. Mais l'inconvénient majeur de CVCS est son point de défaillance unique, c'est-à-dire la défaillance du serveur central. Malheureusement, si le serveur central tombe en panne pendant une heure, alors pendant cette heure, personne ne peut collaborer du tout. Et même dans le pire des cas, si le disque du serveur central est corrompu et qu'une sauvegarde appropriée n'a pas été effectuée, vous perdrez alors tout l'historique du projet. Ici, le système de contrôle de version distribué (DVCS) entre en scène.

Les clients DVCS récupèrent non seulement le dernier instantané du répertoire, mais ils reflètent également entièrement le référentiel. Si le serveur tombe en panne, le référentiel de n'importe quel client peut être recopié sur le serveur pour le restaurer. Chaque extraction est une sauvegarde complète du référentiel. Git ne repose pas sur le serveur central et c'est pourquoi vous pouvez effectuer de nombreuses opérations lorsque vous êtes hors ligne. Vous pouvez valider les modifications, créer des branches, afficher les journaux et effectuer d'autres opérations lorsque vous êtes hors ligne. Vous n'avez besoin d'une connexion réseau que pour publier vos modifications et prendre les dernières modifications.

Avantages de Git

Gratuit et open source

Git est publié sous la licence open source GPL. Il est disponible gratuitement sur Internet. Vous pouvez utiliser Git pour gérer des projets immobiliers sans payer un seul centime. Comme il s'agit d'une open source, vous pouvez télécharger son code source et également effectuer des modifications en fonction de vos besoins.

Rapide et petit

La plupart des opérations étant effectuées localement, cela présente un énorme avantage en termes de rapidité. Git ne repose pas sur le serveur central; c'est pourquoi, il n'est pas nécessaire d'interagir avec le serveur distant pour chaque opération. La partie principale de Git est écrite en C, ce qui évite les surcharges d'exécution associées à d'autres langages de haut niveau. Bien que Git reflète tout le référentiel, la taille des données côté client est petite. Cela illustre l'efficacité de Git dans la compression et le stockage des données côté client.

Sauvegarde implicite

Les chances de perdre des données sont très rares lorsqu'il y en a plusieurs copies. Les données présentes sur n'importe quel côté client reflètent le référentiel, elles peuvent donc être utilisées en cas de panne ou de corruption du disque.

Sécurité

Git utilise une fonction de hachage cryptographique commune appelée fonction de hachage sécurisé (SHA1), pour nommer et identifier les objets dans sa base de données. Chaque fichier et commit est additionné de contrôle et récupéré par sa somme de contrôle au moment de l'extraction. Cela implique qu'il est impossible de modifier le fichier, la date et le message de validation et toute autre donnée de la base de données Git sans connaître Git.

Pas besoin de matériel puissant

Dans le cas du CVCS, le serveur central doit être suffisamment puissant pour répondre aux demandes de toute l'équipe. Pour les petites équipes, ce n'est pas un problème, mais à mesure que la taille de l'équipe augmente, les limitations matérielles du serveur peuvent constituer un goulot d'étranglement des performances. Dans le cas de DVCS, les développeurs n'interagissent pas avec le serveur à moins qu'ils n'aient besoin de pousser ou d'extraire des modifications. Tout le gros du travail se produit du côté client, de sorte que le matériel du serveur peut être très simple.

Branchement plus facile

CVCS utilise un mécanisme de copie bon marché.Si nous créons une nouvelle branche, il copiera tous les codes dans la nouvelle branche, ce qui prend du temps et n'est pas efficace. De plus, la suppression et la fusion de branches dans CVCS sont compliquées et prennent du temps. Mais la gestion des succursales avec Git est très simple. La création, la suppression et la fusion des branches ne prennent que quelques secondes.

Terminologies DVCS

Dépôt local

Chaque outil VCS fournit un lieu de travail privé comme copie de travail. Les développeurs apportent des modifications sur leur lieu de travail privé et après validation, ces modifications deviennent une partie du référentiel. Git va encore plus loin en leur fournissant une copie privée de l'ensemble du référentiel. Les utilisateurs peuvent effectuer de nombreuses opérations avec ce référentiel, telles que l'ajout d'un fichier, la suppression d'un fichier, le renommer un fichier, le déplacement d'un fichier, la validation des modifications, etc.

Répertoire de travail et zone de transit ou index

Le répertoire de travail est l'endroit où les fichiers sont extraits. Dans d'autres CVCS, les développeurs apportent généralement des modifications et commettent leurs modifications directement dans le référentiel. Mais Git utilise une stratégie différente. Git ne suit pas chaque fichier modifié. Chaque fois que vous validez une opération, Git recherche les fichiers présents dans la zone de préparation. Seuls les fichiers présents dans la zone intermédiaire sont pris en compte pour la validation et non tous les fichiers modifiés.

Voyons le flux de travail de base de Git.

Step 1 - Vous modifiez un fichier du répertoire de travail.

Step 2 - Vous ajoutez ces fichiers à la zone de préparation.

Step 3- Vous effectuez une opération de validation qui déplace les fichiers de la zone intermédiaire. Après l'opération push, il stocke les modifications de manière permanente dans le référentiel Git.

Supposons que vous ayez modifié deux fichiers, à savoir «sort.c» et «search.c» et que vous vouliez deux validations différentes pour chaque opération. Vous pouvez ajouter un fichier dans la zone de préparation et faire une validation. Après le premier commit, répétez la même procédure pour un autre fichier.

# First commit
[bash]$ git add sort.c # adds file to the staging area [bash]$ git commit –m “Added sort operation”

# Second commit
[bash]$ git add search.c # adds file to the staging area [bash]$ git commit –m “Added search operation”

Blobs

Blob signifie Binaire Large Object. Chaque version d'un fichier est représentée par blob. Un objet blob contient les données du fichier mais ne contient aucune métadonnée sur le fichier. C'est un fichier binaire, et dans la base de données Git, il est nommé hachage SHA1 de ce fichier. Dans Git, les fichiers ne sont pas adressés par des noms. Tout est axé sur le contenu.

Des arbres

L'arbre est un objet, qui représente un répertoire. Il contient des objets blob ainsi que d'autres sous-répertoires. Un arbre est un fichier binaire qui stocke les références aux objets blob et aux arbres qui sont également nommés commeSHA1 hachage de l'objet arborescent.

S'engage

Commit contient l'état actuel du référentiel. Un commit est également nommé parSHA1hacher. Vous pouvez considérer un objet de validation comme un nœud de la liste liée. Chaque objet de validation a un pointeur vers l'objet de validation parent. À partir d'un commit donné, vous pouvez revenir en arrière en regardant le pointeur parent pour afficher l'historique du commit. Si un commit a plusieurs commits parents, alors ce commit particulier a été créé en fusionnant deux branches.

Branches

Les branches sont utilisées pour créer une autre ligne de développement. Par défaut, Git a une branche principale, qui est la même que le tronc dans Subversion. Habituellement, une branche est créée pour travailler sur une nouvelle fonctionnalité. Une fois la fonctionnalité terminée, elle est fusionnée avec la branche principale et nous supprimons la branche. Chaque branche est référencée par HEAD, qui pointe vers le dernier commit de la branche. Chaque fois que vous effectuez un commit, HEAD est mis à jour avec le dernier commit.

Mots clés

La balise attribue un nom significatif avec une version spécifique dans le référentiel. Les balises sont très similaires aux branches, mais la différence est que les balises sont immuables. Cela signifie que la balise est une branche, que personne n'a l'intention de modifier. Une fois qu'une balise est créée pour un commit particulier, même si vous créez un nouveau commit, il ne sera pas mis à jour. Habituellement, les développeurs créent des balises pour les versions de produits.

Cloner

L'opération de clonage crée l'instance du référentiel. L'opération de clonage extrait non seulement la copie de travail, mais reflète également le référentiel complet. Les utilisateurs peuvent effectuer de nombreuses opérations avec ce référentiel local. Le seul moment où la mise en réseau intervient est lorsque les instances du référentiel sont en cours de synchronisation.

Tirer

L'opération d'extraction copie les modifications d'une instance de référentiel distante vers une instance locale. L'opération d'extraction est utilisée pour la synchronisation entre deux instances de référentiel. Ceci est identique à l'opération de mise à jour dans Subversion.

Pousser

L'opération Push copie les modifications d'une instance de référentiel local vers une instance distante. Ceci est utilisé pour stocker les modifications de manière permanente dans le référentiel Git. Ceci est identique à l'opération de validation dans Subversion.

TÊTE

HEAD est un pointeur, qui pointe toujours vers le dernier commit de la branche. Chaque fois que vous effectuez un commit, HEAD est mis à jour avec le dernier commit. Les têtes des branches sont stockées dans.git/refs/heads/ annuaire.

[CentOS]$ ls -1 .git/refs/heads/ master [CentOS]$ cat .git/refs/heads/master
570837e7d58fa4bccd86cb575d884502188b0c49

Révision

La révision représente la version du code source. Les révisions dans Git sont représentées par des commits. Ces commits sont identifiés parSHA1 hachages sécurisés.

URL

URL représente l'emplacement du référentiel Git. L'URL Git est stockée dans le fichier de configuration.

[tom@CentOS tom_repo]$ pwd /home/tom/tom_repo [tom@CentOS tom_repo]$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = [email protected]:project.git
fetch = +refs/heads/*:refs/remotes/origin/*

Avant de pouvoir utiliser Git, vous devez installer et effectuer quelques modifications de configuration de base. Voici les étapes pour installer le client Git sur Ubuntu et Centos Linux.

Installation de Git Client

Si vous utilisez la distribution GNU / Linux de base Debian, alors apt-get la commande fera le nécessaire.

[ubuntu ~]$ sudo apt-get install git-core [sudo] password for ubuntu: [ubuntu ~]$ git --version
git version 1.8.1.2

Et si vous utilisez une distribution GNU / Linux basée sur RPM, utilisez yum commande comme donnée.

[CentOS ~]$
su -
Password:

[CentOS ~]# yum -y install git-core

[CentOS ~]# git --version
git version 1.7.1

Personnaliser l'environnement Git

Git fournit l'outil git config, qui vous permet de définir des variables de configuration. Git stocke toutes les configurations globales dans.gitconfigfichier, qui se trouve dans votre répertoire personnel. Pour définir ces valeurs de configuration comme globales, ajoutez le--global option, et si vous omettez --global , alors vos configurations sont spécifiques au référentiel Git actuel.

Vous pouvez également configurer une configuration à l'échelle du système. Git stocke ces valeurs dans le/etc/gitconfigfichier, qui contient la configuration de chaque utilisateur et référentiel sur le système. Pour définir ces valeurs, vous devez disposer des droits root et utiliser le--system option.

Lorsque le code ci-dessus est compilé et exécuté, il produit le résultat suivant -

Définition du nom d'utilisateur

Ces informations sont utilisées par Git pour chaque commit.

[jerry@CentOS project]$ git config --global user.name "Jerry Mouse"

Définition de l'identifiant de messagerie

Ces informations sont utilisées par Git pour chaque commit.

[jerry@CentOS project]$ git config --global user.email "[email protected]"

Évitez les commits de fusion pour l'extraction

Vous récupérez les dernières modifications d'un référentiel distant, et si ces modifications sont divergentes, par défaut, Git crée des validations de fusion. Nous pouvons éviter cela via les paramètres suivants.

jerry@CentOS project]$ git config --global branch.autosetuprebase always

Mise en évidence des couleurs

Les commandes suivantes activent la mise en évidence des couleurs pour Git dans la console.

[jerry@CentOS project]$ git config --global color.ui true [jerry@CentOS project]$ git config --global color.status auto

[jerry@CentOS project]$ git config --global color.branch auto

Définition de l'éditeur par défaut

Par défaut, Git utilise l'éditeur par défaut du système, qui est extrait de la variable d'environnement VISUAL ou EDITOR. Nous pouvons en configurer un autre en utilisant git config.

[jerry@CentOS project]$ git config --global core.editor vim

Définition de l'outil de fusion par défaut

Git ne fournit pas d'outil de fusion par défaut pour intégrer les modifications conflictuelles dans votre arbre de travail. Nous pouvons définir l'outil de fusion par défaut en activant les paramètres suivants.

[jerry@CentOS project]$ git config --global merge.tool vimdiff

Liste des paramètres Git

Pour vérifier vos paramètres Git du référentiel local, utilisez git config –list commande comme indiqué ci-dessous.

[jerry@CentOS ~]$ git config --list

La commande ci-dessus produira le résultat suivant.

user.name=Jerry Mouse
[email protected]
push.default=nothing
branch.autosetuprebase=always
color.ui=true
color.status=auto
color.branch=auto
core.editor=vim
merge.tool=vimdiff

Dans ce chapitre, nous discuterons du cycle de vie de Git. Dans les chapitres suivants, nous couvrirons les commandes Git pour chaque opération.

Le flux de travail général est le suivant -

• Vous clonez le référentiel Git en tant que copie de travail.

• Vous modifiez la copie de travail en ajoutant / modifiant des fichiers.

• Si nécessaire, vous mettez également à jour la copie de travail en prenant les modifications d'autres développeurs.

• Vous examinez les modifications avant de valider.

• Vous commettez des changements. Si tout va bien, vous transmettez les modifications au référentiel.

• Après la validation, si vous réalisez que quelque chose ne va pas, vous corrigez la dernière validation et transmettez les modifications au référentiel.

Ci-dessous, la représentation picturale du flux de travail.

Dans ce chapitre, nous verrons comment créer un dépôt Git distant; à partir de maintenant, nous l'appellerons Git Server. Nous avons besoin d'un serveur Git pour permettre la collaboration en équipe.

Créer un nouvel utilisateur

# add new group
[root@CentOS ~]# groupadd dev

# add new user
[root@CentOS ~]# useradd -G devs -d /home/gituser -m -s /bin/bash gituser

# change password
[root@CentOS ~]# passwd gituser

La commande ci-dessus produira le résultat suivant.

Changing password for user gituser.
New password:
Retype new password:
passwd: all authentication token updated successfully.

Créer un référentiel nu

Initialisons un nouveau référentiel en utilisant init commande suivie de --bareoption. Il initialise le référentiel sans répertoire de travail. Par convention, le référentiel nu doit être nommé comme.git.

[gituser@CentOS ~]$ pwd /home/gituser [gituser@CentOS ~]$ mkdir project.git

[gituser@CentOS ~]$ cd project.git/ [gituser@CentOS project.git]$ ls

[gituser@CentOS project.git]$ git --bare init Initialized empty Git repository in /home/gituser-m/project.git/ [gituser@CentOS project.git]$ ls
branches config description HEAD hooks info objects refs

Générer une paire de clés RSA publique / privée

Passons en revue le processus de configuration d'un serveur Git, ssh-keygen L'utilitaire génère une paire de clés RSA publique / privée, que nous utiliserons pour l'authentification des utilisateurs.

Ouvrez un terminal et entrez la commande suivante et appuyez simplement sur Entrée pour chaque entrée. Après avoir réussi, il créera un.ssh répertoire dans le répertoire personnel.

tom@CentOS ~]$ pwd /home/tom [tom@CentOS ~]$ ssh-keygen

La commande ci-dessus produira le résultat suivant.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/tom/.ssh/id_rsa): Press Enter Only
Created directory '/home/tom/.ssh'.
Enter passphrase (empty for no passphrase): ---------------> Press Enter Only
Enter same passphrase again: ------------------------------> Press Enter Only
Your identification has been saved in /home/tom/.ssh/id_rsa.
Your public key has been saved in /home/tom/.ssh/id_rsa.pub.
The key fingerprint is:
df:93:8c:a1:b8:b7:67:69:3a:1f:65:e8:0e:e9:25:a1 tom@CentOS
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
|
.
|
| Soo |
| o*B. |
| E = *.= |
| oo==. . |
| ..+Oo
|
+-----------------+

ssh-keygen a généré deux clés, la première est privée (c'est-à-dire id_rsa) et la seconde est publique (c'est-à-dire id_rsa.pub).

Note: Ne partagez jamais votre clé privée avec d'autres.

Ajout de clés à allowed_keys

Supposons que deux développeurs travaillent sur un projet, à savoir Tom et Jerry. Les deux utilisateurs ont généré des clés publiques. Voyons comment utiliser ces clés pour l'authentification.

Tom a ajouté sa clé publique au serveur en utilisant ssh-copy-id commande comme indiqué ci-dessous -

[tom@CentOS ~]$ pwd /home/tom [tom@CentOS ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

La commande ci-dessus produira le résultat suivant.

[email protected]'s password:
Now try logging into the machine, with "ssh '[email protected]'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

De même, Jerry a ajouté sa clé publique au serveur en utilisant la commande ssh-copy-id.

[jerry@CentOS ~]$ pwd /home/jerry [jerry@CentOS ~]$ ssh-copy-id -i ~/.ssh/id_rsa [email protected]

La commande ci-dessus produira le résultat suivant.

[email protected]'s password:
Now try logging into the machine, with "ssh '[email protected]'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Pousser les modifications dans le référentiel

Nous avons créé un référentiel nu sur le serveur et autorisé l'accès à deux utilisateurs. À partir de maintenant, Tom et Jerry peuvent pousser leurs modifications dans le référentiel en l'ajoutant en tant que télécommande.

La commande Git init crée .git répertoire pour stocker les métadonnées sur le référentiel chaque fois qu'il lit la configuration à partir du .git/config fichier.

Tom crée un nouveau répertoire, ajoute le fichier README et valide sa modification en tant que validation initiale. Après la validation, il vérifie le message de validation en exécutant legit log commander.

[tom@CentOS ~]$ pwd /home/tom [tom@CentOS ~]$ mkdir tom_repo

[tom@CentOS ~]$ cd tom_repo/ [tom@CentOS tom_repo]$ git init
Initialized empty Git repository in /home/tom/tom_repo/.git/

[tom@CentOS tom_repo]$ echo 'TODO: Add contents for README' > README [tom@CentOS tom_repo]$ git status -s
?? README

[tom@CentOS tom_repo]$ git add . [tom@CentOS tom_repo]$ git status -s
A README

[tom@CentOS tom_repo]$ git commit -m 'Initial commit'

La commande ci-dessus produira le résultat suivant.

[master (root-commit) 19ae206] Initial commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README

Tom vérifie le message du journal en exécutant la commande git log.

[tom@CentOS tom_repo]$ git log

La commande ci-dessus produira le résultat suivant.

commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Tom a validé ses modifications dans le référentiel local. Il est maintenant temps de transmettre les modifications au référentiel distant. Mais avant cela, nous devons ajouter le référentiel en tant que distant, c'est une opération ponctuelle. Après cela, il peut transférer en toute sécurité les modifications vers le référentiel distant.

Note- Par défaut, Git pousse uniquement vers les branches correspondantes: pour chaque branche qui existe du côté local, le côté distant est mis à jour si une branche avec le même nom existe déjà là-bas. Dans nos tutoriels, chaque fois que nous apportons des modifications auorigin master succursale, utilisez le nom de succursale approprié selon vos besoins.

[tom@CentOS tom_repo]$ git remote add origin [email protected]:project.git [tom@CentOS tom_repo]$ git push origin master

La commande ci-dessus produira le résultat suivant.

Counting objects: 3, done.
Writing objects: 100% (3/3), 242 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
* [new branch]
master −> master

Désormais, les modifications sont correctement validées dans le référentiel distant.

Nous avons un référentiel nu sur le serveur Git et Tom a également poussé sa première version. Maintenant, Jerry peut voir ses modifications. L'opération de clonage crée une instance du référentiel distant.

Jerry crée un nouveau répertoire dans son répertoire personnel et effectue l'opération de clonage.

[jerry@CentOS ~]$ mkdir jerry_repo [jerry@CentOS ~]$ cd jerry_repo/

[jerry@CentOS jerry_repo]$ git clone [email protected]:project.git

La commande ci-dessus produira le résultat suivant.

Initialized empty Git repository in /home/jerry/jerry_repo/project/.git/
remote: Counting objects: 3, done.
Receiving objects: 100% (3/3), 241 bytes, done.
remote: Total 3 (delta 0), reused 0 (delta 0)

Jerry change le répertoire en nouveau référentiel local et répertorie le contenu de son répertoire.

[jerry@CentOS jerry_repo]$ cd project/

[jerry@CentOS jerry_repo]$ ls
README

Jerry clone le référentiel et décide d'implémenter des opérations de base sur les chaînes. Il crée donc un fichier string.c. Après avoir ajouté le contenu, string.c ressemblera à ceci -

#include <stdio.h>

int my_strlen(char *s)
{
   char *p = s;

   while (*p)
      ++p;

   return (p - s);
}

int main(void)
{
   int i;
   char *s[] = 
   {
      "Git tutorials",
      "Tutorials Point"
   };

   for (i = 0; i < 2; ++i)
      
   printf("string lenght of %s = %d\n", s[i], my_strlen(s[i]));

   return 0;
}

Il a compilé et testé son code et tout fonctionne bien. Désormais, il peut ajouter en toute sécurité ces modifications au référentiel.

L'opération d'ajout de Git ajoute un fichier à la zone de préparation.

[jerry@CentOS project]$ git status -s
?? string
?? string.c

[jerry@CentOS project]$ git add string.c

Git affiche un point d'interrogation avant les noms de fichiers. Évidemment, ces fichiers ne font pas partie de Git, et c'est pourquoi Git ne sait pas quoi faire avec ces fichiers. C'est pourquoi, Git affiche un point d'interrogation avant les noms de fichiers.

Jerry a ajouté le fichier dans la zone de stash, la commande git status affichera les fichiers présents dans la zone de staging.

[jerry@CentOS project]$ git status -s
A string.c
?? string

Pour valider les modifications, il a utilisé la commande git commit suivie de l'option –m. Si nous omettons l'option –m. Git ouvrira un éditeur de texte dans lequel nous pouvons écrire un message de validation multiligne.

[jerry@CentOS project]$ git commit -m 'Implemented my_strlen function'

La commande ci-dessus produira le résultat suivant -

[master cbe1249] Implemented my_strlen function
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 string.c

Après la validation pour afficher les détails du journal, il exécute la commande git log. Il affichera les informations de tous les commits avec leur ID de commit, l'auteur du commit, la date de commit etSHA-1 hachage de commit.

[jerry@CentOS project]$ git log

La commande ci-dessus produira le résultat suivant -

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Après avoir vu les détails du commit, Jerry se rend compte que la longueur de la chaîne ne peut pas être négative, c'est pourquoi il décide de changer le type de retour de la fonction my_strlen.

Jerry utilise le git log commande pour afficher les détails du journal.

[jerry@CentOS project]$ git log

La commande ci-dessus produira le résultat suivant.

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function

Jerry utilise le git showcommande pour afficher les détails de la validation. La commande git show prendSHA-1 commit ID en tant que paramètre.

[jerry@CentOS project]$ git show cbe1249b140dad24b2c35b15cc7e26a6f02d2277

La commande ci-dessus produira le résultat suivant -

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function


diff --git a/string.c b/string.c
new file mode 100644
index 0000000..187afb9
--- /dev/null
+++ b/string.c
@@ -0,0 +1,24 @@
+#include <stdio.h>
+
+int my_strlen(char *s)
+{
   +
   char *p = s;
   +
   +
   while (*p)
   + ++p;
   + return (p -s );
   +
}
+

Il change le type de retour de la fonction de int à size_t. Après avoir testé le code, il passe en revue ses modifications en exécutant legit diff commander.

[jerry@CentOS project]$ git diff

La commande ci-dessus produira le résultat suivant -

diff --git a/string.c b/string.c
index 187afb9..7da2992 100644
--- a/string.c
+++ b/string.c
@@ -1,6 +1,6 @@
#include <stdio.h>

-int my_strlen(char *s)
+size_t my_strlen(char *s)
{
   char *p = s;
   @@ -18,7 +18,7 @@ int main(void)
};
for (i = 0; i < 2; ++i)
{
   - printf("string lenght of %s = %d\n", s[i], my_strlen(s[i]));
   + printf("string lenght of %s = %lu\n", s[i], my_strlen(s[i]));
   return 0;
}

Git diff montre '+' signe avant les lignes, qui sont nouvellement ajoutées et '−' pour les lignes supprimées.

Jerry a déjà validé les changements et il souhaite corriger son dernier commit. Dans ce cas,git amendl'opération aidera. L'opération de modification modifie le dernier commit, y compris votre message de commit; il crée un nouvel ID de validation.

Avant de modifier l'opération, il vérifie le journal de validation.

[jerry@CentOS project]$ git log

La commande ci-dessus produira le résultat suivant.

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Jerry valide les nouvelles modifications avec l'opération de modification et affiche le journal de validation.

[jerry@CentOS project]$ git status -s M string.c ?? string [jerry@CentOS project]$ git add string.c

[jerry@CentOS project]$ git status -s M string.c ?? string [jerry@CentOS project]$ git commit --amend -m 'Changed return type of my_strlen to size_t'
[master d1e19d3] Changed return type of my_strlen to size_t
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 string.c

Maintenant, git log affichera un nouveau message de validation avec un nouvel ID de validation -

[jerry@CentOS project]$ git log

La commande ci-dessus produira le résultat suivant.

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Jerry a modifié son dernier commit en utilisant l'opération d'amendement et il est prêt à pousser les changements. L'opération Push stocke les données de manière permanente dans le référentiel Git. Après une opération push réussie, les autres développeurs peuvent voir les modifications de Jerry.

Il exécute la commande git log pour afficher les détails du commit.

[jerry@CentOS project]$ git log

La commande ci-dessus produira le résultat suivant:

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t

Avant l'opération push, il souhaite revoir ses modifications, il utilise donc le git show commande pour revoir ses modifications.

[jerry@CentOS project]$ git show d1e19d316224cddc437e3ed34ec3c931ad803958

La commande ci-dessus produira le résultat suivant:

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t

diff --git a/string.c b/string.c
new file mode 100644
index 0000000..7da2992
--- /dev/null
+++ b/string.c
@@ -0,0 +1,24 @@
+#include <stdio.h>
+
+size_t my_strlen(char *s)
+
{
   +
   char *p = s;
   +
   +
   while (*p)
   + ++p;
   + return (p -s );
   +
}
+
+int main(void)
+
{
   + int i;
   + char *s[] = 
   {
      + "Git tutorials",
      + "Tutorials Point"
      +
   };
   +
   +
   +
   for (i = 0; i < 2; ++i)
   printf("string lenght of %s = %lu\n", s[i], my_strlen(s[i]));
   +
   +
   return 0;
   +
}

Jerry est content de ses changements et il est prêt à pousser ses changements.

[jerry@CentOS project]$ git push origin master

La commande ci-dessus produira le résultat suivant:

Counting objects: 4, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 517 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
19ae206..d1e19d3 master −> master

Les modifications de Jerry ont été transférées avec succès vers le référentiel; maintenant, d'autres développeurs peuvent afficher ses modifications en effectuant une opération de clonage ou de mise à jour.

Modifier la fonction existante

Tom effectue l'opération de clonage et trouve une nouvelle chaîne de fichier.c. Il veut savoir qui a ajouté ce fichier au référentiel et dans quel but, alors, il exécute legit log commander.

[tom@CentOS ~]$ git clone [email protected]:project.git

La commande ci-dessus produira le résultat suivant -

Initialized empty Git repository in /home/tom/project/.git/
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
Receiving objects: 100% (6/6), 726 bytes, done.
remote: Total 6 (delta 0), reused 0 (delta 0)

L'opération de clonage créera un nouveau répertoire dans le répertoire de travail actuel. Il change le répertoire en répertoire nouvellement créé et exécute legit log commander.

[tom@CentOS ~]$ cd project/

[tom@CentOS project]$ git log

La commande ci-dessus produira le résultat suivant -

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Après avoir observé le journal, il se rend compte que le fichier string.c a été ajouté par Jerry pour implémenter les opérations de base sur les chaînes. Il est curieux du code de Jerry. Il ouvre donc string.c dans l'éditeur de texte et trouve immédiatement un bogue. Dans la fonction my_strlen, Jerry n'utilise pas de pointeur constant. Alors, il décide de modifier le code de Jerry. Après modification, le code se présente comme suit -

[tom@CentOS project]$ git diff

La commande ci-dessus produira le résultat suivant -

diff --git a/string.c b/string.c
index 7da2992..32489eb 100644
--- a/string.c
+++ b/string.c
@@ -1,8 +1,8 @@
#include <stdio.h>
-size_t my_strlen(char *s)
+size_t my_strlen(const char *s)
{
   - char *p = s;
   + const char *p = s;
   while (*p)
   ++p;
}

Après le test, il valide sa modification.

[tom@CentOS project]$ git status -s M string.c ?? string [tom@CentOS project]$ git add string.c

[tom@CentOS project]$ git commit -m 'Changed char pointer to const char pointer' [master cea2c00] Changed char pointer to const char pointer 1 files changed, 2 insertions(+), 2 deletions(-) [tom@CentOS project]$ git log

La commande ci-dessus produira le résultat suivant -

commit cea2c000f53ba99508c5959e3e12fff493b
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 08:32:07 2013 +0530

Changed char pointer to const char pointer


commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530
Initial commit

Tom utilise la commande git push pour pousser ses modifications.

[tom@CentOS project]$ git push origin master

La commande ci-dessus produira le résultat suivant -

Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 336 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
d1e19d3..cea2c00 master −> master

Ajouter une nouvelle fonction

Pendant ce temps, Jerry décide de mettre en œuvre string compareFonctionnalité. Il modifie donc string.c. Après modification, le fichier se présente comme suit -

[jerry@CentOS project]$ git diff

La commande ci-dessus produira le résultat suivant -

index 7da2992..bc864ed 100644
--- a/string.c
+++ b/string.c
30Git Tutorials
@@ -9,9 +9,20 @@ size_t my_strlen(char *s)
return (p -s );
}
+char *my_strcpy(char *t, char *s)
+
{
   +
   char *p = t;
   +
   + while (*t++ = *s++)
   + ;
   +
   +
   return p;
   +
}
+
int main(void)
{
   int i; 
   +
   char p1[32];
   char *s[] = 
   {
      "Git tutorials",
      "Tutorials Point"
      @@ -20,5 +31,7 @@ int main(void)
      for (i = 0; i < 2; ++i)
      printf("string lenght of %s = %lu\n", s[i], my_strlen(s[i]));
      +
      printf("%s\n", my_strcpy(p1, "Hello, World !!!"));
      +
      return 0;
   }
}

Après les tests, il est prêt à pousser son changement.

[jerry@CentOS project]$ git status -s M string.c ?? string [jerry@CentOS project]$ git add string.c

[jerry@CentOS project]$ git commit -m "Added my_strcpy function"
[master e944e5a] Added my_strcpy function
1 files changed, 13 insertions(+), 0 deletions(-)

Avant l'opération push, il vérifie la validation en affichant les messages du journal.

[jerry@CentOS project]$ git log

La commande ci-dessus produira le résultat suivant -

commit e944e5aab74b26e7447d3281b225309e4e59efcd
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:41:42 2013 +0530

Added my_strcpy function


commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Jerry est satisfait des changements et il veut pousser ses changements.

[jerry@CentOS project]$ git push origin master

La commande ci-dessus produira le résultat suivant -

To [email protected]:project.git
! [rejected]
master −> master (non-fast-forward)
error: failed to push some refs to '[email protected]:project.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.

Mais Git ne permet pas à Jerry de pousser ses changements. Parce que Git a identifié que le référentiel distant et le référentiel local de Jerry ne sont pas synchronisés. À cause de cela, il peut perdre l'histoire du projet. Pour éviter ce désordre, Git a échoué cette opération. Maintenant, Jerry doit d'abord mettre à jour le référentiel local et seulement par la suite, il peut pousser ses propres modifications.

Récupérer les dernières modifications

Jerry exécute la commande git pull pour synchroniser son référentiel local avec celui distant.

[jerry@CentOS project]$ git pull

La commande ci-dessus produira le résultat suivant -

remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git.server.com:project
d1e19d3..cea2c00 master −> origin/master
First, rewinding head to replay your work on top of it...
Applying: Added my_strcpy function

Après l'opération d'extraction, Jerry vérifie les messages du journal et trouve les détails de la validation de Tom avec l'ID de validation cea2c000f53ba99508c5959e3e12fff493ba6f69

[jerry@CentOS project]$ git log

La commande ci-dessus produira le résultat suivant -

commit e86f0621c2a3f68190bba633a9fe6c57c94f8e4f
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:41:42 2013 +0530

Added my_strcpy function


commit cea2c000f53ba99508c5959e3e12fff493ba6f69
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 08:32:07 2013 +0530

Changed char pointer to const char pointer


commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530
Initial commit

Désormais, le référentiel local de Jerry est entièrement synchronisé avec le référentiel distant. Il peut donc pousser ses changements en toute sécurité.

[jerry@CentOS project]$ git push origin master

La commande ci-dessus produira le résultat suivant -

Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 455 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
cea2c00..e86f062 master −> master

Supposons que vous implémentiez une nouvelle fonctionnalité pour votre produit. Votre code est en cours et soudainement une escalade client survient. Pour cette raison, vous devez garder de côté votre nouvelle fonctionnalité pendant quelques heures. Vous ne pouvez pas valider votre code partiel et ne pouvez pas non plus rejeter vos modifications. Vous avez donc besoin d'un espace temporaire, où vous pouvez stocker vos modifications partielles et les valider plus tard.

Dans Git, l'opération de mise en cache prend vos fichiers suivis modifiés, met en scène les modifications et les enregistre sur une pile de modifications inachevées que vous pouvez réappliquer à tout moment.

[jerry@CentOS project]$ git status -s
M string.c
?? string

Maintenant, vous voulez changer de succursale pour l'escalade des clients, mais vous ne voulez pas valider ce sur quoi vous avez travaillé encore; vous allez donc cacher les modifications. Pour pousser une nouvelle réserve sur votre pile, exécutez legit stash commander.

[jerry@CentOS project]$ git stash
Saved working directory and index state WIP on master: e86f062 Added my_strcpy function
HEAD is now at e86f062 Added my_strcpy function

Maintenant, votre répertoire de travail est propre et toutes les modifications sont enregistrées sur une pile. Vérifions-le avec legit status commander.

[jerry@CentOS project]$ git status -s
?? string

Vous pouvez désormais changer de branche en toute sécurité et travailler ailleurs. Nous pouvons afficher une liste des modifications cachées en utilisant legit stash list commander.

[jerry@CentOS project]$ git stash list
stash@{0}: WIP on master: e86f062 Added my_strcpy function

Supposons que vous ayez résolu l'escalade des clients et que vous soyez de retour sur votre nouvelle fonctionnalité à la recherche de votre code à moitié terminé, exécutez simplement le git stash pop , pour supprimer les modifications de la pile et les placer dans le répertoire de travail actuel.

[jerry@CentOS project]$ git status -s ?? string [jerry@CentOS project]$ git stash pop

La commande ci-dessus produira le résultat suivant:

# On branch master
# Changed but not updated:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
#
modified: string.c
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
#
string
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (36f79dfedae4ac20e2e8558830154bd6315e72d4)

[jerry@CentOS project]$ git status -s
M string.c
?? string

Comme son nom l'indique, l'opération de déplacement déplace un répertoire ou un fichier d'un emplacement à un autre. Tom décide de déplacer le code source danssrcannuaire. La structure de répertoires modifiée apparaîtra comme suit -

[tom@CentOS project]$ pwd
/home/tom/project

[tom@CentOS project]$ ls README string string.c [tom@CentOS project]$ mkdir src

[tom@CentOS project]$ git mv string.c src/ [tom@CentOS project]$ git status -s
R string.c −> src/string.c
?? string

Pour rendre ces modifications permanentes, nous devons pousser la structure de répertoire modifiée vers le référentiel distant afin que les autres développeurs puissent le voir.

[tom@CentOS project]$ git commit -m "Modified directory structure" [master 7d9ea97] Modified directory structure 1 files changed, 0 insertions(+), 0 deletions(-) rename string.c => src/string.c (100%) [tom@CentOS project]$ git push origin master
Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 320 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
e86f062..7d9ea97 master −> master

Dans le référentiel local de Jerry, avant l'opération d'extraction, il affichera l'ancienne structure de répertoires.

[jerry@CentOS project]$ pwd /home/jerry/jerry_repo/project [jerry@CentOS project]$ ls
README string string.c

Mais après l'opération d'extraction, la structure du répertoire sera mise à jour. Maintenant, Jerry peut voir lesrc répertoire et le fichier présent dans ce répertoire.

[jerry@CentOS project]$ git pull remote: Counting objects: 4, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From git.server.com:project e86f062..7d9ea97 master −> origin/master First, rewinding head to replay your work on top of it... Fast-forwarded master to 7d9ea97683da90bcdb87c28ec9b4f64160673c8a. [jerry@CentOS project]$ ls
README src string

[jerry@CentOS project]$ ls src/
string.c

Jusqu'à présent, Tom et Jerry utilisaient des commandes manuelles pour compiler leur projet. Maintenant, Jerry décide de créer Makefile pour leur projet et de donner également un nom propre au fichier «string.c».

[jerry@CentOS project]$ pwd
/home/jerry/jerry_repo/project

[jerry@CentOS project]$ ls README src [jerry@CentOS project]$ cd src/

[jerry@CentOS src]$ git add Makefile [jerry@CentOS src]$ git mv string.c string_operations.c

[jerry@CentOS src]$ git status -s
A Makefile
R string.c −> string_operations.c

Git montre R avant le nom du fichier pour indiquer que le fichier a été renommé.

Pour l'opération de validation, Jerry a utilisé l'option -a, qui fait que git commit détecte automatiquement les fichiers modifiés.

[jerry@CentOS src]$ git commit -a -m 'Added Makefile and renamed strings.c to
string_operations.c '

[master 94f7b26] Added Makefile and renamed strings.c to string_operations.c
1 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 src/Makefile
rename src/{string.c => string_operations.c} (100%)

Après la validation, il pousse ses modifications dans le référentiel.

[jerry@CentOS src]$ git push origin master

La commande ci-dessus produira le résultat suivant -

Counting objects: 6, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 396 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
7d9ea97..94f7b26 master −> master

Désormais, d'autres développeurs peuvent visualiser ces modifications en mettant à jour leur référentiel local.

Tom met à jour son référentiel local et trouve le binaire compilé dans le srcannuaire. Après avoir vu le message de validation, il se rend compte que le binaire compilé a été ajouté par Jerry.

[tom@CentOS src]$ pwd
/home/tom/project/src

[tom@CentOS src]$ ls Makefile string_operations string_operations.c [tom@CentOS src]$ file string_operations
string_operations: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses
shared libs), for GNU/Linux 2.6.18, not stripped

[tom@CentOS src]$ git log
commit 29af9d45947dc044e33d69b9141d8d2dad37cc62
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:16:25 2013 +0530

Added compiled binary

VCS est utilisé pour stocker uniquement le code source et non les binaires exécutables. Alors, Tom décide de supprimer ce fichier du référentiel. Pour une opération ultérieure, il utilise legit rm commander.

[tom@CentOS src]$ ls
Makefile string_operations string_operations.c

[tom@CentOS src]$ git rm string_operations rm 'src/string_operations' [tom@CentOS src]$ git commit -a -m "Removed executable binary"

[master 5776472] Removed executable binary
1 files changed, 0 insertions(+), 0 deletions(-)
delete mode 100755 src/string_operations

Après la validation, il pousse ses modifications dans le référentiel.

[tom@CentOS src]$ git push origin master

La commande ci-dessus produira le résultat suivant.

Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 310 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
29af9d4..5776472 master −> master

L'erreur est humaine. Ainsi, chaque VCS fournit une fonctionnalité pour corriger les erreurs jusqu'à un certain point. Git fournit une fonctionnalité que nous pouvons utiliser pour annuler les modifications apportées au référentiel local.

Supposons que l'utilisateur effectue accidentellement des modifications dans son référentiel local et souhaite ensuite annuler ces modifications. Dans de tels cas, lerevert l'opération joue un rôle important.

Annuler les modifications non validées

Supposons que Jerry modifie accidentellement un fichier de son référentiel local. Mais il veut annuler sa modification. Pour gérer cette situation, nous pouvons utiliser legit checkoutcommander. Nous pouvons utiliser cette commande pour restaurer le contenu d'un fichier.

[jerry@CentOS src]$ pwd
/home/jerry/jerry_repo/project/src

[jerry@CentOS src]$ git status -s M string_operations.c [jerry@CentOS src]$ git checkout string_operations.c

[jerry@CentOS src]$ git status –s

De plus, nous pouvons utiliser le git checkoutcommande pour obtenir un fichier supprimé du référentiel local. Supposons que Tom supprime un fichier du référentiel local et que nous souhaitons récupérer ce fichier. Nous pouvons y parvenir en utilisant la même commande.

[tom@CentOS src]$ pwd
/home/tom/top_repo/project/src

[tom@CentOS src]$ ls -1 Makefile string_operations.c [tom@CentOS src]$ rm string_operations.c

[tom@CentOS src]$ ls -1 Makefile [tom@CentOS src]$ git status -s
D string_operations.c

Git montre la lettre Davant le nom de fichier. Cela indique que le fichier a été supprimé du référentiel local.

[tom@CentOS src]$ git checkout string_operations.c [tom@CentOS src]$ ls -1
Makefile
string_operations.c

[tom@CentOS src]$ git status -s

Note - Nous pouvons effectuer toutes ces opérations avant de commettre.

Supprimer les modifications de la zone de transit

Nous avons vu que lorsque nous effectuons une opération d'ajout, les fichiers sont déplacés du référentiel local vers la zone de déclaration. Si un utilisateur modifie accidentellement un fichier et l'ajoute dans la zone de préparation, il peut annuler ses modifications, en utilisant legit checkout commander.

Dans Git, il existe un pointeur HEAD qui pointe toujours vers le dernier commit. Si vous souhaitez annuler une modification de la zone intermédiaire, vous pouvez utiliser la commande git checkout, mais avec la commande checkout, vous devez fournir un paramètre supplémentaire, à savoir le pointeur HEAD. Le paramètre de pointeur de validation supplémentaire indique à la commande git checkout de réinitialiser l'arborescence de travail et également de supprimer les modifications par étapes.

Supposons que Tom modifie un fichier de son référentiel local. Si nous visualisons l'état de ce fichier, cela montrera que le fichier a été modifié mais pas ajouté dans la zone de transit.

tom@CentOS src]$ pwd
/home/tom/top_repo/project/src
# Unmodified file

[tom@CentOS src]$ git status -s # Modify file and view it’s status. [tom@CentOS src]$ git status -s
M string_operations.c

[tom@CentOS src]$ git add string_operations.c

Git status montre que le fichier est présent dans la zone de préparation, rétablissez-le maintenant à l'aide de la commande git checkout et affichez l'état du fichier rétabli.

[tom@CentOS src]$ git checkout HEAD -- string_operations.c

[tom@CentOS src]$ git status -s

Déplacer le pointeur HEAD avec Git Reset

Après avoir effectué quelques modifications, vous pouvez décider de supprimer ces modifications. La commande de réinitialisation Git est utilisée pour réinitialiser ou annuler les modifications. Nous pouvons effectuer trois types différents d'opérations de réinitialisation.

Le diagramme ci-dessous montre la représentation graphique de la commande de réinitialisation Git.

Doux

Chaque branche a un pointeur HEAD, qui pointe vers le dernier commit. Si nous utilisons la commande Git reset avec l'option --soft suivie de l'ID de validation, cela réinitialisera le pointeur HEAD uniquement sans rien détruire.

.git/refs/heads/masterLe fichier stocke l'ID de validation du pointeur HEAD. Nous pouvons le vérifier en utilisant legit log -1 commander.

[jerry@CentOS project]$ cat .git/refs/heads/master
577647211ed44fe2ae479427a0668a4f12ed71a1

Maintenant, affichez le dernier ID de validation, qui correspondra à l'ID de validation ci-dessus.

[jerry@CentOS project]$ git log -2

La commande ci-dessus produira le résultat suivant.

commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary


commit 29af9d45947dc044e33d69b9141d8d2dad37cc62
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:16:25 2013 +0530

Added compiled binary

Réinitialisons le pointeur HEAD.

[jerry@CentOS project]$ git reset --soft HEAD~

Maintenant, nous réinitialisons simplement le pointeur HEAD d'une position. Laissez-nous vérifier le contenu de.git/refs/heads/master file.

[jerry@CentOS project]$ cat .git/refs/heads/master
29af9d45947dc044e33d69b9141d8d2dad37cc62

L'ID de validation du fichier est modifié, vérifiez-le maintenant en affichant les messages de validation.

jerry@CentOS project]$ git log -2

La commande ci-dessus produira le résultat suivant.

commit 29af9d45947dc044e33d69b9141d8d2dad37cc62
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:16:25 2013 +0530

Added compiled binary


commit 94f7b26005f856f1a1b733ad438e97a0cd509c1a
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:08:01 2013 +0530

Added Makefile and renamed strings.c to string_operations.c

mixte

Git reset avec l'option --mixed annule les modifications de la zone de préparation qui n'ont pas encore été validées. Il annule uniquement les modifications de la zone de transit. Les modifications réelles apportées à la copie de travail du fichier ne sont pas affectées. La réinitialisation par défaut de Git est équivalente à la réinitialisation de git - mixed.

dur

Si vous utilisez l'option --hard avec la commande Git reset, cela effacera la zone de préparation; il réinitialisera le pointeur HEAD à la dernière validation de l'ID de validation spécifique et supprimera également les modifications du fichier local.

Vérifions l'ID de validation.

[jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git log -1

La commande ci-dessus produira le résultat suivant.

commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary

Jerry a modifié un fichier en ajoutant un commentaire sur une seule ligne au début du fichier.

[jerry@CentOS src]$ head -2 string_operations.c
/* This line be removed by git reset operation */
#include <stdio.h>

Il l'a vérifié en utilisant la commande git status.

[jerry@CentOS src]$ git status -s
M string_operations.c

Jerry ajoute le fichier modifié à la zone de préparation et le vérifie avec la commande git status.

[jerry@CentOS src]$ git add string_operations.c [jerry@CentOS src]$ git status

La commande ci-dessus produira le résultat suivant.

# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#
modified: string_operations.c
#

L'état de Git indique que le fichier est présent dans la zone de préparation. Maintenant, réinitialisez HEAD avec l'option - hard.

[jerry@CentOS src]$ git reset --hard 577647211ed44fe2ae479427a0668a4f12ed71a1

HEAD is now at 5776472 Removed executable binary

La commande de réinitialisation Git a réussi, ce qui rétablira le fichier de la zone de préparation et supprimera toutes les modifications locales apportées au fichier.

[jerry@CentOS src]$ git status -s

Le statut Git indique que le fichier a été rétabli de la zone de préparation.

[jerry@CentOS src]$ head -2 string_operations.c
#include <stdio.h>

La commande head montre également que l'opération de réinitialisation a également supprimé les modifications locales.

L'opération de balise permet de donner des noms significatifs à une version spécifique dans le référentiel. Supposons que Tom et Jerry décident de baliser le code de leur projet afin de pouvoir y accéder plus tard facilement.

Créer des balises

Marquons le HEAD actuel en utilisant le git tagcommander. Tom fournit un nom de balise avec l'option -a et fournit un message de balise avec l'option –m.

tom@CentOS project]$ pwd
/home/tom/top_repo/project

[tom@CentOS project]$ git tag -a 'Release_1_0' -m 'Tagged basic string operation code' HEAD

Si vous souhaitez baliser une validation particulière, utilisez l'ID COMMIT approprié au lieu du pointeur HEAD. Tom utilise la commande suivante pour pousser la balise dans le référentiel distant.

[tom@CentOS project]$ git push origin tag Release_1_0

La commande ci-dessus produira le résultat suivant -

Counting objects: 1, done.
Writing objects: 100% (1/1), 183 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
* [new tag]
Release_1_0 −> Release_1_0

Afficher les balises

Tom a créé des balises. Maintenant, Jerry peut afficher toutes les balises disponibles en utilisant la commande balise Git avec l'option –l.

[jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git pull
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), done.
From git.server.com:project
* [new tag]
Release_1_0 −> Release_1_0
Current branch master is up to date.

[jerry@CentOS src]$ git tag -l
Release_1_0

Jerry utilise la commande Git show suivie de son nom de balise pour afficher plus de détails sur la balise.

[jerry@CentOS src]$ git show Release_1_0

La commande ci-dessus produira le résultat suivant -

tag Release_1_0
Tagger: Tom Cat <[email protected]>
Date: Wed Sep 11 13:45:54 2013 +0530

Tagged basic string operation code


commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary

diff --git a/src/string_operations b/src/string_operations
deleted file mode 100755
index 654004b..0000000
Binary files a/src/string_operations and /dev/null differ

Supprimer les balises

Tom utilise la commande suivante pour supprimer les balises du référentiel local et distant.

[tom@CentOS project]$ git tag Release_1_0 [tom@CentOS project]$ git tag -d Release_1_0
Deleted tag 'Release_1_0' (was 0f81ff4)
# Remove tag from remote repository.

[tom@CentOS project]$ git push origin :Release_1_0
To [email protected]:project.git
- [deleted]
Release_1_0

Patch est un fichier texte, dont le contenu est similaire à Git diff, mais avec le code, il contient également des métadonnées sur les commits; par exemple, l'ID de validation, la date, le message de validation, etc. Nous pouvons créer un patch à partir des validations et d'autres personnes peuvent les appliquer à leur référentiel.

Jerry implémente la fonction strcat pour son projet. Jerry peut créer un chemin de son code et l'envoyer à Tom. Ensuite, il peut appliquer le patch reçu à son code.

Jerry utilise le Git format-patchcommande pour créer un patch pour le dernier commit. Si vous souhaitez créer un patch pour un commit spécifique, utilisezCOMMIT_ID avec la commande format-patch.

[jerry@CentOS project]$ pwd
/home/jerry/jerry_repo/project/src

[jerry@CentOS src]$ git status -s M string_operations.c ?? string_operations [jerry@CentOS src]$ git add string_operations.c

[jerry@CentOS src]$ git commit -m "Added my_strcat function" [master b4c7f09] Added my_strcat function 1 files changed, 13 insertions(+), 0 deletions(-) [jerry@CentOS src]$ git format-patch -1
0001-Added-my_strcat-function.patch

La commande ci-dessus crée .patchfichiers dans le répertoire de travail actuel. Tom peut utiliser ce patch pour modifier ses fichiers. Git fournit deux commandes pour appliquer des correctifsgit amet git apply, respectivement. Git apply modifie les fichiers locaux sans créer de validation, tandis que git am modifie le fichier et crée également un commit.

Pour appliquer le correctif et créer un commit, utilisez la commande suivante -

[tom@CentOS src]$ pwd /home/tom/top_repo/project/src [tom@CentOS src]$ git diff

[tom@CentOS src]$ git status –s [tom@CentOS src]$ git apply 0001-Added-my_strcat-function.patch

[tom@CentOS src]$ git status -s
M string_operations.c
?? 0001-Added-my_strcat-function.patch

Le patch est appliqué avec succès, maintenant nous pouvons voir les modifications en utilisant le git diff commander.

[tom@CentOS src]$ git diff

La commande ci-dessus produira le résultat suivant -

diff --git a/src/string_operations.c b/src/string_operations.c
index 8ab7f42..f282fcf 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,5 +1,16 @@
#include <stdio.h>
+char *my_strcat(char *t, char *s)
diff --git a/src/string_operations.c b/src/string_operations.c
index 8ab7f42..f282fcf 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,5 +1,16 @@
#include <stdio.h>
+char *my_strcat(char *t, char *s)
+
{
   +
   char *p = t;
   +
   +
   +
   while (*p)
   ++p;
   +
   while (*p++ = *s++)
   + ;
   + return t;
   +
}
+
size_t my_strlen(const char *s)
{
   const char *p = s;
   @@ -23,6 +34,7 @@ int main(void)
   {

L'opération de branche permet de créer une autre ligne de développement. Nous pouvons utiliser cette opération pour bifurquer le processus de développement dans deux directions différentes. Par exemple, nous avons publié un produit pour la version 6.0 et nous pourrions vouloir créer une branche afin que le développement des fonctionnalités 7.0 puisse être séparé des corrections de bogues 6.0.

Créer une branche

Tom crée une nouvelle branche à l'aide de la commande git branch <nom de la branche>. Nous pouvons créer une nouvelle branche à partir d'une branche existante. Nous pouvons utiliser un commit ou une balise spécifique comme point de départ. Si aucun ID de validation spécifique n'est fourni, la branche sera créée avec HEAD comme point de départ.

[jerry@CentOS src]$ git branch new_branch [jerry@CentOS src]$ git branch
* master
new_branch

Une nouvelle branche est créée; Tom a utilisé la commande git branch pour lister les branches disponibles. Git montre un astérisque avant la branche actuellement extraite.

La représentation graphique de l'opération de création de branche est indiquée ci-dessous -

Basculer entre les branches

Jerry utilise la commande git checkout pour basculer entre les branches.

[jerry@CentOS src]$ git checkout new_branch Switched to branch 'new_branch' [jerry@CentOS src]$ git branch
master
* new_branch

Raccourci pour créer et changer de branche

Dans l'exemple ci-dessus, nous avons utilisé deux commandes pour créer et changer de branche, respectivement. Git fournit–boption avec la commande checkout; cette opération crée une nouvelle branche et bascule immédiatement vers la nouvelle branche.

[jerry@CentOS src]$ git checkout -b test_branch Switched to a new branch 'test_branch' [jerry@CentOS src]$ git branch
master
new_branch
* test_branch

Supprimer une branche

Une branche peut être supprimée en fournissant l'option –D avec la commande git branch. Mais avant de supprimer la branche existante, passez à l'autre branche.

Jerry est actuellement sur test_branchet il veut supprimer cette branche. Il change donc de branche et supprime la branche comme indiqué ci-dessous.

[jerry@CentOS src]$ git branch master new_branch * test_branch [jerry@CentOS src]$ git checkout master
Switched to branch 'master'

[jerry@CentOS src]$ git branch -D test_branch
Deleted branch test_branch (was 5776472).

Maintenant, Git n'affichera que deux branches.

[jerry@CentOS src]$ git branch
* master
new_branch

Renommer une branche

Jerry décide d'ajouter la prise en charge des caractères larges dans son projet d'opérations de chaîne. Il a déjà créé une nouvelle branche, mais le nom de la branche n'est pas approprié. Il change donc le nom de la branche en utilisant–m option suivie de la old branch name et le new branch name.

[jerry@CentOS src]$ git branch * master new_branch [jerry@CentOS src]$ git branch -m new_branch wchar_support

Maintenant, la commande git branch affichera le nouveau nom de la branche.

[jerry@CentOS src]$ git branch
* master
wchar_support

Fusionner deux branches

Jerry implémente une fonction pour renvoyer la longueur de la chaîne de caractères large. Nouveau le code apparaîtra comme suit -

[jerry@CentOS src]$ git branch
master
* wchar_support

[jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git diff

La commande ci-dessus produit le résultat suivant -

t a/src/string_operations.c b/src/string_operations.c
index 8ab7f42..8fb4b00 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,4 +1,14 @@
#include <stdio.h>
+#include <wchar.h>
+
+size_t w_strlen(const wchar_t *s)
+
{
   +
   const wchar_t *p = s;
   +
   +
   while (*p)
   + ++p;
   + return (p - s);
   +
}

Après le test, il s'engage et applique ses modifications à la nouvelle branche.

[jerry@CentOS src]$ git status -s M string_operations.c ?? string_operations [jerry@CentOS src]$ git add string_operations.c

[jerry@CentOS src]$ git commit -m 'Added w_strlen function to return string lenght of wchar_t
string'

[wchar_support 64192f9] Added w_strlen function to return string lenght of wchar_t string
1 files changed, 10 insertions(+), 0 deletions(-)

Notez que Jerry pousse ces changements vers la nouvelle branche, c'est pourquoi il a utilisé le nom de la branche wchar_support au lieu de master branche.

[jerry@CentOS src]$ git push origin wchar_support  <−−− Observer branch_name

La commande ci-dessus produira le résultat suivant.

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 507 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
* [new branch]
wchar_support -> wchar_support

Après avoir validé les modifications, la nouvelle branche apparaîtra comme suit -

Tom est curieux de savoir ce que fait Jerry dans sa succursale privée et il vérifie le journal du wchar_support branche.

[tom@CentOS src]$ pwd /home/tom/top_repo/project/src [tom@CentOS src]$ git log origin/wchar_support -2

La commande ci-dessus produira le résultat suivant.

commit 64192f91d7cc2bcdf3bf946dd33ece63b74184a3
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 16:10:06 2013 +0530

Added w_strlen function to return string lenght of wchar_t string


commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary

En visualisant les messages de validation, Tom se rend compte que Jerry a implémenté la fonction strlen pour les caractères larges et il veut la même fonctionnalité dans la branche principale. Au lieu de ré-implémenter, il décide de prendre le code de Jerry en fusionnant sa branche avec la branche master.

[tom@CentOS project]$ git branch * master [tom@CentOS project]$ pwd
/home/tom/top_repo/project

[tom@CentOS project]$ git merge origin/wchar_support
Updating 5776472..64192f9
Fast-forward
src/string_operations.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)

Après l'opération de fusion, la branche principale apparaîtra comme suit -

Maintenant, la branche wchar_supporta été fusionné avec la branche principale. Nous pouvons le vérifier en visualisant le message de validation ou en visualisant les modifications effectuées dans le fichier string_operation.c.

[tom@CentOS project]$ cd src/

[tom@CentOS src]$ git log -1

commit 64192f91d7cc2bcdf3bf946dd33ece63b74184a3
Author: Jerry Mouse 
      
        Date: Wed Sep 11 16:10:06 2013 +0530 Added w_strlen function to return string lenght of wchar_t string [tom@CentOS src]$ head -12 string_operations.c 
      

La commande ci-dessus produira le résultat suivant.

#include <stdio.h>
#include <wchar.h>
size_t w_strlen(const wchar_t *s)
{
   const wchar_t *p = s;

   while (*p)
      ++p;

   return (p - s);
}

Après les tests, il transmet ses modifications de code à la branche principale.

[tom@CentOS src]$ git push origin master
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
5776472..64192f9 master −> master

Rebase Branches

La commande Git rebase est une commande de fusion de branche, mais la différence est qu'elle modifie l'ordre des commits.

La commande Git merge essaie de placer les commits d'autres branches au-dessus de la HEAD de la branche locale actuelle. Par exemple, votre branche locale a des commits A−> B−> C−> D et la branche merge a des commits A−> B−> X−> Y, alors git merge convertira la branche locale actuelle en quelque chose comme A−> B−> C−> D−> X−> Y

La commande Git rebase tente de trouver l'ancêtre commun entre la branche locale actuelle et la branche de fusion. Il pousse ensuite les commits vers la branche locale en modifiant l'ordre des commits dans la branche locale actuelle. Par exemple, si votre branche locale a des commits A−> B−> C−> D et que la branche de fusion a des commits A−> B−> X−> Y, alors Git rebase convertira la branche locale actuelle en quelque chose comme A− > B−> X−> Y−> C−> D.

Lorsque plusieurs développeurs travaillent sur un même référentiel distant, vous ne pouvez pas modifier l'ordre des validations dans le référentiel distant. Dans ce cas, vous pouvez utiliser l'opération de rebase pour placer vos validations locales au-dessus des validations du référentiel distant et vous pouvez appliquer ces modifications.

Effectuer des modifications dans la branche wchar_support

Jerry travaille sur le wchar_supportbranche. Il change le nom des fonctions et après les tests, il valide ses modifications.

[jerry@CentOS src]$ git branch
 master
* wchar_support
[jerry@CentOS src]$ git diff

La commande ci-dessus produit le résultat suivant -

diff --git a/src/string_operations.c b/src/string_operations.c
index 8fb4b00..01ff4e0 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,7 +1,7 @@
#include <stdio.h>
#include <wchar.h>
-size_t w_strlen(const wchar_t *s)
+size_t my_wstrlen(const wchar_t *s)
{
   const wchar_t *p = s;

Après avoir vérifié le code, il valide ses modifications.

[jerry@CentOS src]$ git status -s
M string_operations.c

[jerry@CentOS src]$ git add string_operations.c [jerry@CentOS src]$ git commit -m 'Changed function name'
[wchar_support 3789fe8] Changed function name
1 files changed, 1 insertions(+), 1 deletions(-)

[jerry@CentOS src]$ git push origin wchar_support

La commande ci-dessus produira le résultat suivant -

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 409 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
64192f9..3789fe8 wchar_support -> wchar_support

Effectuer des changements dans la branche principale

Pendant ce temps, dans la branche master, Tom change également le nom de la même fonction et pousse ses modifications dans la branche master.

[tom@CentOS src]$ git branch
* master
[tom@CentOS src]$ git diff

La commande ci-dessus produit le résultat suivant -

diff --git a/src/string_operations.c b/src/string_operations.c
index 8fb4b00..52bec84 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,7 +1,8 @@
#include <stdio.h>
#include <wchar.h>
-size_t w_strlen(const wchar_t *s)
+/* wide character strlen fucntion */
+size_t my_wc_strlen(const wchar_t *s)
{
   const wchar_t *p = s;

Après avoir vérifié diff, il valide ses modifications.

[tom@CentOS src]$ git status -s
M string_operations.c

[tom@CentOS src]$ git add string_operations.c [tom@CentOS src]$ git commit -m 'Changed function name from w_strlen to my_wc_strlen'
[master ad4b530] Changed function name from w_strlen to my_wc_strlen
1 files changed, 2 insertions(+), 1 deletions(-)

[tom@CentOS src]$ git push origin master

La commande ci-dessus produira le résultat suivant -

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 470 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
64192f9..ad4b530 master -> master

Sur le wchar_supportbranche, Jerry implémente la fonction strchr pour une chaîne de caractères large. Après le test, il s'engage et pousse ses modifications vers lewchar_support branche.

[jerry@CentOS src]$ git branch
master
* wchar_support
[jerry@CentOS src]$ git diff

La commande ci-dessus produit le résultat suivant -

diff --git a/src/string_operations.c b/src/string_operations.c
index 01ff4e0..163a779 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,6 +1,16 @@
#include <stdio.h>
#include <wchar.h>
+wchar_t *my_wstrchr(wchar_t *ws, wchar_t wc)
+
{
   +
   while (*ws) 
   {
      +
      if (*ws == wc)
      +
      return ws;
      +
      ++ws;
      + 
   }
   + return NULL;
   +
}
+
size_t my_wstrlen(const wchar_t *s)
{
   const wchar_t *p = s;

Après vérification, il valide ses modifications.

[jerry@CentOS src]$ git status -s
M string_operations.c

[jerry@CentOS src]$ git add string_operations.c [jerry@CentOS src]$ git commit -m 'Addded strchr function for wide character string'
[wchar_support 9d201a9] Addded strchr function for wide character string
1 files changed, 10 insertions(+), 0 deletions(-)

[jerry@CentOS src]$ git push origin wchar_support

La commande ci-dessus produira le résultat suivant -

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 516 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
3789fe8..9d201a9 wchar_support -> wchar_support

Lutter contre les conflits

Tom veut voir ce que Jerry fait sur sa branche privée alors, il essaie de tirer les dernières modifications du wchar_support branch, mais Git abandonne l'opération avec le message d'erreur suivant.

[tom@CentOS src]$ git pull origin wchar_support

La commande ci-dessus produit le résultat suivant -

remote: Counting objects: 11, done.
63Git Tutorials
remote: Compressing objects: 100% (8/8), done.
remote: Total 8 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
From git.server.com:project
* branch
wchar_support -> FETCH_HEAD
Auto-merging src/string_operations.c
CONFLICT (content): Merge conflict in src/string_operations.c
Automatic merge failed; fix conflicts and then commit the result.

Résoudre des conflits

D'après le message d'erreur, il est clair qu'il y a un conflit dans src / string_operations.c. Il exécute la commande git diff pour afficher plus de détails.

[tom@CentOS src]$ git diff

La commande ci-dessus produit le résultat suivant -

diff --cc src/string_operations.c
index 52bec84,163a779..0000000
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@@ -1,8 -1,17 +1,22 @@@
#include <stdio.h>
#include <wchar.h>
++<<<<<<< HEAD
+/* wide character strlen fucntion */
+size_t my_wc_strlen(const wchar_t *s)
++=======
+ wchar_t *my_wstrchr(wchar_t *ws, wchar_t wc)
+
{
   +
   +
   while (*ws) 
   {
      if (*ws == wc)
      +
      return ws;
      +
      ++ws;
      + 
   }
   + return NULL;
   +
}
+
+ size_t my_wstrlen(const wchar_t *s)
++>>>>>>>9d201a9c61bc4713f4095175f8954b642dae8f86
{
   const wchar_t *p = s;

Comme Tom et Jerry ont changé le nom de la même fonction, Git est dans un état de confusion et il demande à l'utilisateur de résoudre le conflit manuellement.

Tom décide de garder le nom de la fonction suggéré par Jerry, mais il garde le commentaire ajouté par lui, tel quel. Après avoir supprimé les marqueurs de conflit, git diff ressemblera à ceci.

[tom@CentOS src]$ git diff

La commande ci-dessus produit le résultat suivant.

diff --cc src/string_operations.c
diff --cc src/string_operations.c
index 52bec84,163a779..0000000
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@@ -1,8 -1,17 +1,18 @@@
#include <stdio.h>
#include <wchar.h>
+ wchar_t *my_wstrchr(wchar_t *ws, wchar_t wc)
+
{
   +
   while (*ws) 
   {
      +
      if (*ws == wc)
      +
      return ws;
      +
      ++ws;
      + 
   }
   + return NULL;
   +
}
+
+/* wide character strlen fucntion */
- size_t my_wc_strlen(const wchar_t *s)
+ size_t my_wstrlen(const wchar_t *s)
{
   const wchar_t *p = s;

Comme Tom a modifié les fichiers, il doit d'abord valider ces modifications et ensuite, il peut extraire les modifications.

[tom@CentOS src]$ git commit -a -m 'Resolved conflict' [master 6b1ac36] Resolved conflict [tom@CentOS src]$ git pull origin wchar_support.

Tom a résolu le conflit, maintenant l'opération d'extraction réussira.

Utilisations GNU / Linux et Mac OS line-feed (LF), ou nouvelle ligne comme caractère de fin de ligne, alors que Windows utilise line-feed and carriage-return (LFCR) combinaison pour représenter le caractère de fin de ligne.

Pour éviter les commits inutiles à cause de ces différences de fin de ligne, nous devons configurer le client Git pour écrire la même fin de ligne dans le référentiel Git.

Pour le système Windows, nous pouvons configurer le client Git pour convertir les fins de ligne en CRLF format lors de l'extraction, et les reconvertir en LFformat pendant l'opération de validation. Les paramètres suivants feront le nécessaire.

[tom@CentOS project]$ git config --global core.autocrlf true

Pour GNU / Linux ou Mac OS, nous pouvons configurer le client Git pour convertir les fins de ligne à partir de CRLF à LF lors de l'exécution de l'opération de vérification.

[tom@CentOS project]$ git config --global core.autocrlf input

GitHubest un service d'hébergement Web pour les projets de développement logiciel qui utilise le système de contrôle de révision Git. Il a également leur application GUI standard disponible au téléchargement (Windows, Mac, GNU / Linux) directement à partir du site Web du service. Mais dans cette session, nous ne verrons que la partie CLI.

Créer un référentiel GitHub

Accédez à github.com . Si vous possédez déjà leGitHubcompte, puis connectez-vous à l'aide de ce compte ou créez-en un nouveau. Suivez les étapes du site Web github.com pour créer un nouveau référentiel.

Opération Push

Tom décide d'utiliser le GitHubserveur. Pour démarrer un nouveau projet, il crée un nouveau répertoire et un fichier à l'intérieur.

[tom@CentOS]$ mkdir github_repo [tom@CentOS]$ cd github_repo/

[tom@CentOS]$ vi hello.c [tom@CentOS]$ make hello
cc hello.c -o hello

[tom@CentOS]$ ./hello

La commande ci-dessus produira le résultat suivant:

Hello, World !!!

Après avoir vérifié son code, il initialise le répertoire avec la commande git init et valide ses modifications localement.

[tom@CentOS]$ git init
Initialized empty Git repository in /home/tom/github_repo/.git/

[tom@CentOS]$ git status -s ?? hello ?? hello.c [tom@CentOS]$ git add hello.c

[tom@CentOS]$ git status -s A hello.c ?? hello [tom@CentOS]$ git commit -m 'Initial commit'

Après cela, il ajoute le GitHub l'URL du référentiel en tant qu'origine distante et pousse ses modifications vers le référentiel distant.

[tom@CentOS]$ git remote add origin https://github.com/kangralkar/testing_repo.git [tom@CentOS]$ git push -u origin master

L'opération push demandera GitHubnom d'utilisateur et mot de passe. Une fois l'authentification réussie, l'opération réussira.

La commande ci-dessus produira le résultat suivant:

Username for 'https://github.com': kangralkar
Password for 'https://[email protected]': 
Counting objects: 3, done.
Writing objects: 100% (3/3), 214 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/kangralkar/test_repo.git
 * [new branch]      master −> master
 Branch master set up to track remote branch master from origin.

À partir de maintenant, Tom peut appliquer les modifications GitHubdépôt. Il peut utiliser toutes les commandes décrites dans ce chapitre avec leGitHub dépôt.

Opération de traction

Tom a poussé avec succès toutes ses modifications à GitHubdépôt. Désormais, d'autres développeurs peuvent afficher ces modifications en effectuant une opération de clonage ou en mettant à jour leur référentiel local.

Jerry crée un nouveau répertoire dans son répertoire personnel et clone le GitHub référentiel à l'aide de la commande git clone.

[jerry@CentOS]$ pwd /home/jerry [jerry@CentOS]$ mkdir jerry_repo

[jerry@CentOS]$ git clone https://github.com/kangralkar/test_repo.git

La commande ci-dessus produit le résultat suivant:

Cloning into 'test_repo'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.

Il vérifie le contenu du répertoire en exécutant la commande ls.

[jerry@CentOS]$ ls
test_repo

[jerry@CentOS]$ ls test_repo/
hello.c