Nous avons vu la semaine dernière comment initialiser son projet avec GIT sous VSTS. Aujourd'hui nous allons nous concentrer sur la création de commits et les moyens de partager ces commits entre un serveur et notre repository local.

Creation d'un commit

Pour rappel, un commit est une unité de travail listant des modifications apportées au repository. GIT se base sur un historique de commit pour mettre à jour un repository. Cependant, avant de pouvoir créer un commit, il est nécessaire de comprendre de quoi nous allons le constituer.

Visualisation des modifications en attente

Une fois le repository initialisé, il est donc possible de commencer à en modifier le contenu. GIT fonctionne de façon autonome, c'est à dire que vous n'avez pas besoin d'avoir Visual Studio d'ouvert pour retenir les modifications effectuées. Vous pouvez donc travailler avec n'importe quel éditeur et même directement dans l'explorateur de fichier. Avant de pouvoir créer un commit et donc de persister les modifications apportées au repository, nous allons dans un premier temps pouvoir en faire la liste. Cette liste reprendra donc la totalité des modifications apportées au repository depuis le précédent commit (ce sont les modifications qui ne sont pas encore indexées).

Visual Studio

Dans Team Explorer, l’onglet changes permet de voir les modifications en attente et d’obtenir une description de la modification apportée (suppression du fichier, ajout, ou modification du contenu) comme le montre la capture suivante :

Un double clic sur un fichier modifié affichera un outil de différentiel entre le fichier actuel et sa version précédente.

Astuces

Il est possible d’ignorer un fichier en l’état « add » via un clic droit et de créer une règle (sauvegardée ensuite dans le fichier gitignore) selon son chemin ou son extension.

Command Line

En ligne de commande, l’action status permet de lister les modifications en attente de commit :

git status

On peut y voir une première liste de fichier contenant les modifications apportées aux fichiers déjà présents dans le contrôle de code source, ainsi qu’une seconde présentant les nouveaux fichiers.

Créer un commit

Après avoir identifié les modifications intéressantes, il est possible de les regrouper au sein d’un commit. Par principe, on fait en général le nécessaire pour inclure les modifications liées entre elles au sein d’un même commit. Le niveau de granularité à adopter pour déterminer si une modification est liée à une autre dépend évidemment de l’équipe et du projet, mais on peut retenir quelques règles de base comme le fait de produire un commit lorsque la solution compile. En effet cela peut avoir son importance si l’on considère qu’à tout moment on peut faire revenir la solution à l’état de ce commit particulier. Mais cette technique est aussi parfois (souvent) trop contraignante et on s’astreindra en général à créer des commits avec des modifications que l’on peut facilement décrire dans le commentaire associé.

Team Explorer

Dans l’onglet des changements de Team Explorer, vous pourrez ajouter un commit avec l’ensemble des modifications en attente. Il est évidemment possible d’ajouter un commentaire à ce commit. Pour isoler des modifications à ajouter au commit (si vous ne voulez donc pas tout commiter d’un coup), il est possible d’utiliser l’action stage (via clic droit on via le bouton +).

Il est aussi possible d’annuler les modifications apportées au fichier et de revenir à son état initial (en date du dernier commit) via l’action « Undo Changes… ».

Command Line

En ligne de commande, l’action commit et ses multiples options permettent de créer un commit. Pour créer un commit avec toutes les modifications en cours, il faut utiliser l’option -a :

git commit -a

Attention toutefois, les nouveaux fichiers (untracked) ne sont pas pris en compte par cette dernière option. Pour cela, il est nécessaire de préparer le prochain commit à l’aide de l’action add. Cette dernière est identique à l’action stage vu précédemment et dispose d’ailleurs d’un alias du même nom. Pour utiliser la commande add, il est possible de se baser sur le retour de la commande status : on pourra ainsi ajouter au prochain commit les modifications voulues en copiant collant le chemin des modifications.

git add <path/to/my/file>

Pour ajouter à l’espace de staging l’ensemble des modifications présente dans le répertoire courant et les sous dossiers, utiliser la commande suivante :

git add .

L’action commit permettra ensuite de créer un commit avec les modifications de l’espace de staging. Pour spécifier un message à associer au commit, utiliser l’option -m :

git commit -m "<message>"

Astuces

Si vous n’utilisez pas l’option -m, vous tomberez certainement dans l’éditeur VIM inclus avec GIT, afin de fournir ce message. Les utilisateurs de linux ne seront peut-être pas rebutés par cette outil d’un autre temps, mais cela peut être assez déconcertant lorsque l’on ne connait pas. Voici quelques conseils pour vous en sortir si besoin :

1. Admettons que vous ayez déjà fait plusieurs tentatives, mais que vous soyez toujours bloqué dans VIM, il vaut certainement mieux quitter sans sauvegarder les modifications et reprendre sur de bonnes bases ensuite, suivez donc la séquence de touche suivante : [escp]:q[enter]
2. Lorsque VIM s’ouvre, vous vous trouvez dans le mode qui vous permet d’effectuer des opérations sur le document et de choisir un nouveau mode, nommons le mode global pour plus de simplicité. Pour passer du mode global au mode insertion et pouvoir saisir le message du commit, appuyer sur la touche i. Vous pouvez ensuite écrire le message directement.
3. Pour quitter le mode insertion et revenir au mode global, utiliser la touche [escp].
4. Pour valider le commit et le message (depuis le mode global), utiliser la séquence de touche suivante : :wq[enter]. La touche : signifie que vous voulez opérer sur le document, w pour write signifie que vous voulez persister les modifications (le message) apportées et q pour quit pour sortir de VIM. Si toutefois vous ne souhaitez pas sauvegarder votre message et valider le commit, vous pourrez utiliser la séquence à suivre : :q![enter].

 Partage d'un commit

Récupérer les modifications d’un repository (PULL)

Après avoir réalisé un ou plusieurs commits locaux, il est généralement recommandé de récupérer les modifications apportées au repository distant. On va ainsi pouvoir réaliser un merge entre les commits locaux en attente et les commits distant. Pour récupérer les commits distant, on parle de l’action PULL. Il arrive aussi que l’on évoque la commande FETCH. La différence entre les deux est la suivante : FETCH récupère les commits distants et permet de les consulter, mais ne les applique pas sur le système de fichier, alors que PULL récupère les commits distants et les applique.

Team Explorer

L’onglet synchronization de Team Explorer permet de réaliser les actions PULL et PUSH entre autres. Voici ce que l’on pourrait obtenir après un FETCH :

Avec un clic droit, il est possible d’inspecter les commits listés dans la section entrante. Le bouton PULL permettra donc d’en appliquer les modifications sur le repository local.

Command Line

Avec la ligne de commande, les actions précédentes s’effectuent ainsi :

git fetch

Pour simplement lister les commits entrant, et la suivante pour les appliquer :

git pull

Gestion des conflits

Lorsque les modifications effectuées dans vos commits locaux sont en conflit avec celles qui se trouvent sur le repository distant, vous serez obligé de résoudre ces modifications (l’opération push ne sera pas possible).

Team Explorer

Lorsque vous vous apprêtez à récupérer les commits distants, comme sur l’image précédente, GIT peut détecter un conflit comme suit :

Parfois, le conflit peut être automatiquement géré, mais dans le cas contraire, vous devrez le résoudre en cliquant sur le lien « Resolve the conflicts » ou le lien « Conflicts :1 ». L’interface de gestion du conflit (très pratique) se présente ainsi et est très similaire à ce que l’on connait sur TFS :

Une fois un conflit géré, GIT demande de créer un nouveau commit représentant cette résolution :

Il apparait donc ensuite dans la liste des commits sortant que l’on enverra au serveur via un push :

Command Line

En ligne de commande, après un pull, il se peut qu’un conflit survienne, ce qui se présentera potentiellement de la manière suivante :

Il faut donc ensuite éditer les fichiers en cause manuellement (ici on peut voir que seul src/main.h est concerné). GIT ajoute des modifications aux fichiers de sorte à guider le merge :

On peut ainsi voir après la section HEAD les modifications retenues dans le commit local en conflit avec la section suivante (séparé par des signe « = ») dont le nom est l’identifiant de commit. Il faut ensuite ne conserver que le code final en nettoyant le fichier comme suit :

Partager les modifications d’un repository (PUSH)

Une fois un ou plusieurs commits effectués, les éventuelles modifications du repository distant rapatriées, l’action PUSH permet de partager ses propres modifications. Cette action n’est pas possible si certains de vos commits locaux entre en conflit avec les nouveaux (par rapport à votre version du repository local) se trouvant sur le repository maître. Vous devrez alors d’abords faire un PULL.

Team Explorer

Il faut donc utiliser le bouton push de la section des commits sortant.

Command Line

En ligne de commande, l’action status donnera le nombre de commit effectués qui n’ont pas encore été partagés. La commande suivante les transférera au repository distant :

git push

 

 Avec ce que nous venons de voir, nous sommes maintenant capable de gérer basiquement notre repository en créant des commits, en les mergeant avec d'autres commits du serveur distant et en y poussant nos propres commits. La prochaine fois nous verrons comment gérer les branches avec GIT.