Comprendre le contrôle de code source Git dans Xcode

Une partie importante du processus de développement d'une application est la façon dont les développeurs parviennent à garder trace des modifications apportées au code au fil du temps. Elle se compose en fait d'un besoin de stocker et gérer les copies des versions du code à différentes phases stables et de pouvoir revenir en arrière quand des bogues ou autres problèmes surgissent. Encore plus, quand un certain nombre de programmeurs travaillent au même projet, le suivi de toutes les modifications est obligatoire. Heureusement, les développeurs n'ont pas à mettre au point leur propre façon de faire tout cela, car il existe des solutions logicielles spéciales, appelées systèmes de contrôle de versions.

Un système de contrôle de versions, ou en d'autres termes un système de contrôle de révisions, est en fait un mécanisme (logiciel) capable de surveiller les modifications apportées aux fichiers de code au fil du temps et de les stocker pour référence ultérieure. À part cela, il peut aussi enregistrer des données supplémentaires essentielles telles que le développeur qui a fait les modifications, quand cela a été fait, ce qui a été modifié et d'autres genres de données de l'historique. Par ailleurs, un tel système offre la possibilité de comparer les différentes versions du code, de revenir à une version précédente, soit des fichiers spécifiques, soit de l'ensemble d'un projet si nécessaire et finalement, de mettre en œuvre un produit sans bogues, en traquant tout le code malveillant.

En utilisant un système de contrôle de versions, les développeurs peuvent travailler sur les différents chemins d'un projet couramment appelés branches, et lorsque leur partie de projet est prête, tout est mis ensemble de sorte que la version définitive de l'application peut être construite. Ce processus est appelé fusion(1) et représente une caractéristique particulière des systèmes de contrôle de versions. En fait, cette façon de travailler est obligatoire pour les équipes de développeurs et les compagnies d'édition de logiciels, où chacun est responsable d'une partie du projet et à la fin, tout doit être rassemblé et mis en place.

Les développeurs individuels ne sont pas obligés d'utiliser un système de contrôle de versions, mais cela est fortement recommandé, pour la facilité de dépister les bogues ou de revenir aux versions de code stables et fonctionnelles si nécessaire. La vérité est qu'un grand nombre de programmeurs qui travaillent seuls, surtout les nouveaux, n'utilisent pas du tout un tel système et généralement, ils conservent manuellement des copies de leurs projets quand ils sont sur le point d'y ajouter de nouvelles fonctionnalités ou de les modifier en général. C'est une très mauvaise habitude, car un système de contrôle de code source gère cela beaucoup mieux et plus efficacement, en fournissant en même temps toutes les fonctionnalités supplémentaires décrites précédemment.

L'un des systèmes de contrôle de versions les plus connus (sinon le plus célèbre) est git, développé à l'origine par le créateur de Linux, Linus Torvalds. Git organise tout dans des répertoires virtuels, nommés référentiels(2), auxquels il applique effectivement des suivis de versions. Il peut être utilisé soit en ligne de commande, soit par l'intermédiaire des applications de bureau conçues spécialement. Si git vous est inconnu, je vous suggère de lire un peu plus à son sujet sur le web, car en discuter plus en détail serait hors des possibilités de ce tutoriel.

Depuis la version 5, Xcode intègre une fonctionnalité enrichie pour travailler avec git et un menu complet avec différentes options et sous-menus a été mis en place pour gérer le contrôle du code source. Comme vous le verrez par la suite, travailler avec git et le contrôle de versions est assez facile et rapide et une fois que vous aurez terminé le tutoriel, vous n'aurez plus aucune excuse pour ne pas l'utiliser.

Pour conclure cette introduction : comme vous l'avez déjà compris, notre mission est d'apprendre comment travailler avec git et le contrôle de versions par le biais de Xcode et tout cela sera réalisé en apprenant à connaître chaque caractéristique connexe fournie par Xcode. Si vous ne vous sentez pas familier avec tout cela, ou si vous avez besoin d'acquérir un peu plus de connaissances avant de commencer, alors veuillez rechercher des informations sur le web. Je dois dire à l'avance que durant le tutoriel, je présume que vous avez les connaissances minimales requises sur les systèmes de contrôle de versions et sur git, car nous les tiendrons pour acquis et nous allons nous concentrer principalement sur la façon dont Xcode gère tout cela.

Contrairement à d'autres tutoriels, pour celui-ci nous n'allons pas mettre en œuvre une application qui explique une fonctionnalité spécifique du SDK iOS, ni n'aurons à la fin une petite application mise à point. Ce que nous ferons en fait, ce sera de créer un projet de démonstration juste pour ajouter quelques lignes de code à différents moments et de l'utiliser comme un outil pour tester toutes les options de gestion de contrôle du code source que Xcode fournit. En d'autres termes, nous allons nous concentrer sur l'EDI et pas sur iOS.

En plus, cette fois-ci il n'y a pas une application à télécharger. Je vous invite plutôt à mettre en œuvre le projet de démonstration étape par étape et y ajouter manuellement le code là où c'est nécessaire (ne vous inquiétez pas, il n'y en aura pas beaucoup). Il faut suivre cette voie, car nous allons effectuer de façon répétée différentes actions liées au contrôle de versions et nous devons voir les résultats en temps réel. Cela ne serait pas possible si je fournissais juste une application avec toutes les actions déjà réalisées, car alors la pratique de votre part serait égale à zéro.

Alors, commençons et regardons en détail l'essentiel du contrôle de versions à l'aide de Xcode.

Chaque fois qu'un nouveau projet est créé avec Xcode, une option donne toujours au développeur la possibilité d'ajouter un référentiel git local. La création d'un projet c'est un processus en trois étapes et lors de la troisième et dernière étape, Xcode fournit une case à cocher avec le message approprié, qui, si elle est sélectionnée, fait que le référentiel git est ajouté au répertoire du projet. Il est facile d'ignorer cette option, ou de la considérer comme une autre caractéristique inutile de Xcode et c'est ce qui se passe généralement, surtout dans le cas des développeurs qui n'ont jamais utilisé le contrôle de versions et git ou sont nouveaux à la programmation.

Pour tout voir en détail, lancez Xcode et créez un nouveau projet. Sélectionnez comme modèle d'application Single View Application, dans la catégorie Application de la section iOS.

Cliquez sur le bouton Next pour passer à la deuxième étape. Dans le champ Product Name, définissez GitDemo comme nom du projet et assurez-vous que la valeur iPhone est sélectionnée dans le menu déroulant Devices. Pas besoin ici d'un iPad ou d'une application universelle.

Cliquez encore une fois sur le bouton Next et laissez-vous guider vers la troisième et dernière étape. Ici, dans un premier temps sélectionnez un répertoire pour enregistrer le projet. Ensuite, regardez en bas de la fenêtre et remarquez une case à cocher avec le texte Create git repository on (My Mac) :

Cette option est toujours activée par défaut et un référentiel git est créé avec chaque projet. Au cas où vous ne voulez pas utiliser git et le contrôle de versions dans votre projet, il suffit de la désélectionner, mais je le déconseille. Quoi qu'il en soit, dans ce tutoriel nous voulons qu'elle soit activée, alors assurez-vous que vous activez la case à cocher. Enfin, cliquez sur le bouton Create.

Attendez que le projet soit créé, puis ouvrez une fenêtre du Finder et accédez au répertoire où vous avez enregistré le projet. Là, recherchez le sous-répertoire .git, créé automatiquement par Xcode pour y stocker les données liées au référentiel git.

Si vous ne parvenez pas à voir le répertoire .git, vous devrez rendre visibles les fichiers cachés sur votre ordinateur. Pour ce faire, ouvrez une fenêtre du Terminal et tapez les commandes suivantes :

Pour OS X Mavericks 10.9 :

defaults write com.apple.finder AppleShowAllFiles TRUE

Pour les versions d'OS X antérieures :

defaults write com.apple.Finder AppleShowAllFiles TRUE

Ensuite, il suffit de recharger l'application Finder, il faut donc ajouter encore une commande :

killall Finder

Comme vous le voyez, ici est enregistré votre référentiel git local créé pour cette application. En conséquence, un sous-répertoire .git est toujours créé avec toute nouvelle application, pour autant que vous laissiez l'option correspondante activée.

Il est évident que l'ajout d'un référentiel git à un projet Xcode se fait sans aucun effort. Cependant, que se passe-t-il si vous n'ajoutez pas un référentiel git lors de la configuration du projet, ou si vous souhaitez en ajouter un par la suite ? Eh bien, la bonne nouvelle est que vous pouvez ajouter un référentiel pour votre projet à tout moment, mais sans utiliser Xcode et même si cela arrive moins souvent, je vais vous montrer comment faire.

Notez que si vous le souhaitez, vous pouvez ignorer ceci et passer à la partie suivante du tutoriel. Cependant, je vous recommanderais de continuer à lire l'information fournie à ce sujet, car elle est très utile.

Avant de présenter quoi que ce soit, vous devez télécharger les outils de ligne de commande à l'aide de Xcode, car nous allons travailler dans Terminal et nous aurons besoin de quelques outils supplémentaires. Si vous avez déjà téléchargé ce paquetage, continuez la lecture. Si ce n'est pas le cas, pour installer les outils de ligne de commande allez dans le menu Xcode > Préférences, puis sélectionnez l'onglet Downloads. Dans la partie supérieure de la fenêtre, sous la section Components, cliquez sur le bouton avec une flèche vers le bas situé à droite de l'option Command Line Tools. Une fois le téléchargement terminé, une coche apparaît à la place du bouton de téléchargement :

Maintenant, créez encore un projet Xcode pour les besoins de cet exemple, vous allez le supprimer lorsque nous serons passés par toutes les étapes. Assurez-vous de désélectionner l'option Create git repository. Dans ce cas, nous ne voulons pas que Xcode crée un référentiel pour nous. Nommez le projet NoGitExample et enregistrez-le sur votre Bureau, afin de pouvoir suivre les commandes que je vais montrer.

Une fois que tout est prêt, ouvrez une fenêtre du Terminal (si vous en avez déjà ouvert une, assurez-vous d'abord de la fermer, pour que chaque modification apportée par l'installation des outils de ligne de commande soit prise en compte). Pour commencer, accédez au répertoire du nouveau projet :

cd /Users/YOUR-USERNAME/Desktop/NoGitExample

N'oubliez pas de renseigner votre nom d'utilisateur Mac dans la commande ci-dessus. Ensuite :

git init

Cette commande va initialiser un référentiel vide et si vous allez à Finder ou utilisez la commande ls, vous verrez que le sous-répertoire .git a été créé. C'est génial. Continuez :

git add .

Avec celle-ci, tout le contenu du répertoire courant (le symbole point [.]) sera ajouté au référentiel. Enfin, faire commit du tout (rendre les modifications permanentes) :

git commit -m 'Initial commit'

Dans la fenêtre du terminal s'affiche la liste de tous les fichiers sauvegardés dans le référentiel git local. L'image suivante montre mon terminal :

Le référentiel git est prêt, mais si vous retournez à Xcode et ouvrez le menu Source Control, vous verrez que tout est toujours désactivé.

C'est parce que Xcode n'est pas averti automatiquement de l'ajout manuel de notre référentiel git. Alors, fermez Xcode en utilisant le menu Xcode > Quit Xcode et rouvrez-le. Maintenant, si vous ouvrez à nouveau le menu Source Control dans le projet NoGitExample, vous verrez que toutes les options ont été activées, comme si nous avions ajouté le référentiel git lors de la création du projet.

À ce stade, vous pouvez fermer le projet NoGitExample et le supprimer de votre bureau.

Désormais, vous savez comment ajouter un référentiel git pour chacun de vos projets et même si vous l'avez omis intentionnellement ou accidentellement lors de la configuration du projet, vous pouvez l'ajouter manuellement à tout moment.

Quand nous parlons d'enregistrer des changements dans un référentiel, nous voulons dire stocker une nouvelle version de notre projet, contenant toutes les modifications qui lui ont été apportées telles que des fichiers modifiés ou nouvellement ajoutés. En général, un enregistrement devrait avoir lieu quand une quantité remarquable de travail est accomplie et le projet se trouve dans un état stable. Il n'y a aucune règle générale sur la fréquence des enregistrements, mais je voudrais vous suggérer que : si vous pensez que le travail fait depuis la dernière fois où vous avez enregistré des modifications dans le référentiel va coûter beaucoup de temps et d'efforts si vous le gâchez par accident, il est certainement temps pour un nouveau commit.

Xcode fait par défaut un enregistrement lorsqu'un nouveau projet est créé. Son but est de garder une version du projet dans son état initial. Cela se passe dans les coulisses, sans vous déranger ou vous demander une confirmation quelconque. Si vous n'ajoutez pas un référentiel git lors de la création d'un nouveau projet, mais que vous le faites manuellement plus tard, comme indiqué dans la partie précédente, la première validation est effectuée avec la commande: git commit-m 'Initial commit' que nous avons utilisée tout à l'heure.

En fait, vous pouvez visualiser les informations concernant la validation initiale en allant dans le menu Source Control > History : chaque commit du projet que vous avez effectué y est enregistré.

Maintenant, apportons quelques modifications au projet. Ouvrez le fichier ViewController.m, et dans la section classe privée ajoutez la déclaration de propriété suivante :

@interface ViewController ()

@property (nonatomic) int sum;

@end

Ensuite, modifiez la méthode viewDidLoad comme ceci :

- (void)viewDidLoad

{
     [super viewDidLoad
];
     // Débarrassez-vous des ressources qui peuvent être recréées.

     int a = 5;
     int b = 10;

     self.sum = a + b;

     NSLog("The result is: %d", self.sum);
}

Si vous regardez le volet du navigateur de projet, vous remarquerez que la lettre M a été ajoutée à côté du fichier ViewController.m, comme dans l'image suivante :

Cela signifie que le fichier a été modifié, et il y a des changements par rapport à la dernière version enregistrée de celui-ci. Généralement, chaque fois que vous modifiez un fichier, la lettre M indique qu'il y a de nouveaux changements, pas encore enregistrés.

Voyons maintenant comment faire commit. C'est très simple, et il suffit d'utiliser le menu Source Control > Commit. La fenêtre suivante apparaît :

Voyons ce qu'on nous dit, étape par étape. Dans le volet de gauche (indiqué par 1) sont répertoriés tous les fichiers modifiés. Dans notre cas, uniquement ViewController.m a été modifié, il est donc le seul affiché ici. Si vous regardez attentivement, vous verrez qu'il y a une case à cocher à gauche du fichier, cochée par défaut. Si vous la décochez, les modifications apportées au fichier ne seront pas enregistrées, mais maintenant ce n'est pas ce que nous désirons, alors laissez-la cochée.

Dans la zone centrale de la fenêtre (indiquée par 2) se trouvent deux volets de prévisualisation. Dans celui de gauche, il y a la version actuelle du fichier (pas encore enregistrée) et dans celui de droite, la dernière version enregistrée du même fichier. Comme le seul commit était celui par défaut, sur cette capture d'écran est représenté l'état d'origine du fichier ViewController.m.

Les zones bleues dans le volet de gauche, se terminant à droite par des lignes (indiquées par 3), sont les changements réels apportés au fichier. Ce genre de représentation rend immédiatement visibles toutes les modifications et l'endroit (numéro de ligne) où elles ont été faites. Vous pouvez remarquer au centre de la fenêtre, entre les deux volets d'aperçu, quelques petites étiquettes arrondies, avec un nombre dessus (indiquées par 4). Ces nombres sur les étiquettes comptent tous les changements un par un. À leur gauche se trouve un symbole coche. Lorsque celui-ci apparaît, le changement respectif sera normalement enregistré dans le référentiel. Cependant, vous pouvez choisir d'enregistrer une ou plusieurs modifications d'un fichier, ou même les rejeter, si vous cliquez sur la petite flèche à droite du nombre. Un petit menu avec deux options s'affiche :

Si vous sélectionnez l'option Don't Commit, la coche est remplacée par un symbole stop et la modification respective ne sera pas enregistrée dans le référentiel.

Si vous sélectionnez dans le menu l'option Discard Change, une fenêtre de confirmation apparaîtra pour vous informer que la modification sélectionnée sera annulée et qu'il n'y aura pas moyen de la récupérer.

Si vous cliquez sur le bouton OK, les modifications apportées à la zone sélectionnée disparaîtront, comme si elles n'avaient jamais existé.

Si vous regardez attentivement l'image de la fenêtre de commit ci-dessus, vous verrez que toutes les modifications sont considérées par Xcode comme des changements, même une ligne vide. En fait, les lignes vides contiennent des caractères qui ne sont pas visibles à l'écran, il est donc tout à fait raisonnable de les ajouter à la collection de modifications.

Quoi qu'il en soit, pour la réussite de cet exemple assurez-vous de ne rejeter aucune modification et d'autoriser tous les enregistrements, en gardant le symbole coche sur chaque étiquette.

En dessous des deux volets, il y a une zone blanche, avec le message Enter commit message here au milieu. Cette zone est prévue pour ajouter une courte description des modifications apportées dans cette version. Cliquez dessus et ajoutez le message « Une propriété pour la somme a été déclarée. La première addition a été faite et enregistrée dans le débogueur. » comme sur l'image suivante :

Écrire des messages (ayant un sens) d'enregistrement c'est utile, surtout si vous commencez à faire commit souvent. Alors, pensez-y comme à une action nécessaire.

Maintenant que nous avons fait le tour de l'essentiel de cette fenêtre, il est temps de faire notre premier commit. Dans le coin inférieur droit de la fenêtre se trouve un bouton Commit 1 file.

Sur ce bouton apparaîtra toujours le nombre total de fichiers à enregistrer. Cliquez dessus et félicitations ! Votre premier commit est effectif et il appartient maintenant à l'histoire, tant métaphoriquement que littéralement. Que veux-je dire ? Il suffit d'ouvrir le menu Source Control > History et vous verrez qu'il est ajouté à la liste.

Comme vous voyez, le message que nous avons écrit s'y trouve, ainsi que le nombre de fichiers modifiés. Dans le premier commit fait par Xcode, tous les fichiers ont été enregistrés, mais cette fois-ci, seulement celui que nous avons modifié.

À part cela, si vous fermez la fenêtre de l'historique et regardez le volet du Navigateur du projet, le M indiqué à côté du fichier ViewController.m est parti aussi !

Maintenant, préparons-nous pour un autre commit. Cette fois, nous allons ajouter quelques nouveaux fichiers à notre projet, et la meilleure façon de faire cela est de créer une nouvelle classe. Donc, appuyez sur la combinaison de touches Commande-N de votre clavier et ajoutez une classe Objective-C. Faites-en une sous-classe de la classe NSObject, et nommez-la TestClass. Enfin, ajoutez-la au projet.

Une fois que vous avez fait tout cela, remarquez dans le volet du navigateur du projet qu'une nouvelle indication avec la lettre A est apparue à côté des deux fichiers de classe. Cela signifie que ces fichiers ont été ajoutés au projet et bien sûr, qu'ils n'ont pas encore été enregistrés.

Ouvrez le fichier ViewController.h et importez notre classe :

#import "TestClass.h"

Ensuite, ouvrez le fichier ViewController.m et déclarez une propriété privée comme suit :

@interface ViewController ()

@property (nonatomic) int sum;

@property (nonatomic, strong) TestClass *testClass;

@end

Regardez à nouveau le navigateur de projet et remarquez que cette fois-ci, il y a quatre fichiers non sauvegardés : les deux fichiers de classe que nous avons ajoutés tout à l'heure et les deux fichiers modifiés existants. Validons ces changements via le menu Source Control > Commit.

Cette fois, il y a au total cinq fichiers sélectionnés pour commit. Le cinquième (présenté en premier dans la ligne) est le fichier de paramètres du projet, modifié automatiquement par Xcode lorsque la nouvelle classe a été ajoutée au projet. Si vous cliquez sur le fichier TestClass.h ou TestClass.m, le volet de gauche apparaîtra sans contenu, comme illustré ici :

Cela arrive parce qu'il n'existe pas de sauvegarde précédente de ces deux fichiers, donc il n'y a pas de version antérieure pour faire une comparaison. Alors, voir écrit dans le volet de droite simplement File was added est tout à fait normal.

Allez à la zone de message et ajoutez le message de commit suivant : la classe TestClass a été ajoutée au projet. Après cela, cliquez sur le bouton Commit 5 files et laissez Xcode enregistrer les changements dans le référentiel git.

Le deuxième commit manuel a été fait avec succès. Vous pouvez vérifier cela si vous ouvrez l'historique dans le menu Source Control > History :

Après avoir enregistré différentes versions de votre projet, c'est assez facile de les comparer et de traquer les modifications du code. Comparer les versions est particulièrement important lorsque le code nouvellement ajouté ne fonctionne pas comme c'était prévu et vous devez trouver toutes les modifications apportées depuis la dernière version stable.

Pour comparer deux versions différentes d'un fichier, soit utilisez View > Version Editor > Show Version Editor, soit cliquez sur le bouton Version Editor de la barre d'outils indiqué ci-dessous :

Après avoir entrepris une de ces deux actions, l'éditeur se divise en deux parties. Initialement, ces deux volets montrent la version actuelle du fichier sélectionné. Pour afficher une version précédente dans l'un des deux volets, allez à la barre d'outils en dessous du volet et cliquez sur le dernier bouton, celui avec l'image d'une horloge :

Immédiatement, toutes les modifications correspondant à la sélection sont affichées à l'écran. Habituellement, le volet de gauche est utilisé pour la version actuelle du fichier, tandis que celui de droite est utilisé pour accéder à une version précédente. Les zones bleues indiquent le code modifié ce qui rend le suivi des ajouts de code très simple. Donc, allez-y et sélectionnez n'importe quel commit précédent et regardez les différences apparues entre les deux volets.

Comme vous pouvez le constater, entre les deux volets de l'éditeur se trouvent les étiquettes arrondies que nous avons vues pour la première fois dans la fenêtre de validation. En cliquant sur la flèche figurant sur l'une d'elles, l'option pour annuler les modifications respectives apparaît. Si vous cliquez dessus, Xcode demandera votre confirmation et si vous acceptez, le code sélectionné sera effacé définitivement, sans aucune chance de le récupérer. Alors, faites attention de ne pas supprimer une partie du code, même accidentellement.

En plus de la modalité présentée ci-dessus, il y en a une autre que vous pouvez utiliser pour revenir aux révisions précédentes. Si vous examinez attentivement la barre d'outils sous les deux volets, au milieu de celle-ci il y a un bouton avec une horloge et une flèche.

Si vous cliquez dessus, la colonne entre les deux volets change et les étiquettes sont remplacées par une série d'horodateurs de toutes les sauvegardes précédentes. Notez que tous ne représentent pas une modification effective, le nombre réel de ces rectangles arrondis correspondant aux versions précédentes dépend de la quantité des commit. Par exemple, dans notre application uniquement les deux formes en bas correspondent à des commit réels.

En bas de cette colonne se trouvent deux flèches. Celle appartenant au volet de gauche pointe vers la droite et celle du volet de droite pointe vers la gauche. Déplacez une de ces flèches vers n'importe quelle révision précédente et vous la verrez apparaître instantanément dans le volet respectif. Si vous voulez comparer la version actuelle avec une des précédentes, faites pointer une flèche vers la ligne locale et déplacez l'autre. L'ordre des horodateurs, de bas en haut, est du plus récent au plus ancien. Cela signifie que dans la ligne intitulée base, vous avez le dernier commit fait précédemment et si vous vous déplacez vers le haut, vous rencontrerez les commit les plus anciens. La capture d'écran suivante reprend tout ce que je viens de décrire :

À présent, vous savez comment comparer des versions et suivre des modifications au fil du temps, alors n'hésitez pas à jouer avec cette fonctionnalité avant d'aller plus loin.

En plus de la comparaison des versions de fichiers, Xcode permet de retrouver la personne qui a fait un commit, ainsi que celle qui a modifié des parties de code. C'est une fonctionnalité très utile dans les cas de projets où travaillent plusieurs développeurs. Pour l'utiliser, il suffit soit d'ouvrir le menu View > Version Editor > Show Blame View, soit de maintenir enfoncé le bouton de la souris sur le bouton Version Editor de la barre d'outils et ensuite sélectionner l'option Blame. Une fenêtre similaire à celle-ci s'affichera :

Comme vous voyez, le code du fichier sélectionné est séparé en segments par des lignes horizontales qui correspondent à des commit spécifiques. L'auteur de chaque segment de code, ainsi que le message du commit et quelques autres informations s'affichent à droite de la fenêtre, à l'intérieur d'un volet spécial.

Ouvrez la vue Blame si vous ne l'avez pas encore fait et remarquez la façon dont Xcode présente les parties de code séparées par commit et auteur. Pour un extrait de code spécifique, c'est très rapide et facile à repérer quand il a été enregistré et par qui et encore quelques autres informations supplémentaires si vous le souhaitez. Cette information supplémentaire peut être visualisée si vous passez le pointeur de la souris sur le volet de blâme. Vous verrez que lorsque le pointeur se trouve sur un segment sauvegardé, un petit bouton avec un i apparaît à droite de celui-ci. Si vous cliquez dessus, le code du segment est sélectionné, et un popup apparaît avec toutes les informations du commit. À partir de ce popup, vous pouvez également accéder à la fenêtre de comparaison (indication 1) et aux fichiers modifiés dans le commit en question (indication 2).

En plus de la vue de comparaison - expliquée dans la section précédente - et la vue blâme dont nous venons de parler, il y a aussi la vue Log. Elle est accessible via View > Version Editor > Show Log View ou en maintenant enfoncé le bouton de la souris sur le bouton Version Editor de la barre d'outils et sélectionner l'option Log. Je n'entrerai pas dans les détails de ce sujet, je vous laisse le découvrir. Après tout, il n'est pas difficile de comprendre à quoi sert le journal et comment on peut l'utiliser.

Imaginez que vous ayez une version fonctionnelle d'un projet prête à être publiée, ou déjà sortie, et maintenant vous voulez commencer à développer une nouvelle fonctionnalité, mais vous ne voulez pas détruire par accident l'application stable actuelle. Que pouvez-vous faire dans ce cas, afin d'éviter une possible catastrophe et de veiller à ce que votre projet ne soit pas modifié à tort ? La réponse est simple : utiliser des branches.

Pour bien comprendre ce que c'est une branche, pensez à votre projet comme à un arbre, dont le tronc est toujours sa version principale, stable et fonctionnelle. Chaque nouvelle fonctionnalité ou modification apportée à l'application doit faire partie du tronc pour passer en production. Une branche dans les systèmes de contrôle de versions est comme la branche de l'arbre, qui commence à partir du tronc et pousse dans une direction différente. En git (et en Xcode), vous pouvez créer des branches pour définir de nouvelles directions pour votre code (comme la mise en œuvre de nouvelles fonctionnalités), sans risquer de briser la version fonctionnelle au cours du développement.

En fait, une branche par défaut appelée master est toujours créée en git. Le commit initial effectué par Xcode s'effectue dans cette branche. Les développeurs individuels travaillent d'habitude uniquement dans la branche master, même si c'est une mauvaise pratique. Peu importe si vous travaillez seul ou en équipe, je pense que c'est très important d'utiliser des branches quand vous voulez faire des modifications essentielles ou des ajouts à votre application, car cette tactique peut vous éviter des ennuis. Bien sûr, dans les projets d'équipe c'est presque obligatoire de développer votre partie du projet dans une branche distincte.

Il est important d'avoir à l'esprit deux faits :

1. Le produit final qui est sur le point d'être livré à App Store ou à un client est toujours la version du projet existante sur la branche master ;
2. Tout code ou fonctionnalité implémentés dans des branches secondaires doivent être finalement fusionnées à la branche master, afin d'être inclus dans la version officielle de l'application (à ce sujet plus tard).

Lorsque vous commencez à travailler dans une nouvelle branche, vous commencez en fait du point où vous êtes actuellement, même si vous avez des modifications non validées. À partir de là, toutes les modifications du code seront disponibles uniquement dans la nouvelle branche.

Revenons à Xcode maintenant. Pour créer une nouvelle branche, allez dans le menu Source Control > GitDemo - master > New Branch, et vous verrez apparaître la fenêtre suivante :

Ajoutez un nom pour la branche. Moi, je l'ai appelée (comme vous le voyez dans l'image ci-dessus) AnotherBranch, mais son nom n'a pas d'importance. Ensuite, cliquez sur le bouton Create et attendez un moment jusqu'à ce que la nouvelle branche soit créée et le code actuel y soit copié.

Vous pouvez très facilement identifier votre branche active. Il suffit d'ouvrir le menu Source Control, et à côté du nom du projet, vous verrez la branche courante.

Maintenant, faisons un commit de la nouvelle branche. Avant cela, nous ajouterons un peu de code, alors allez dans la section de la classe privée et ajoutez cette déclaration de méthode :

@interface ViewController ()

 ...

-(void)sayHello;

@end

Ensuite, son implémentation :

-(void)sayHello{
     NSLog("Hello");
}

Enfin, son appel dans la méthode viewDidLoad :

- (void)viewDidLoad 
{
     ...    

     [self sayHello];
}

Maintenant, allez dans le menu Source Control > Commit et la fenêtre de comparaison de versions apparaîtra. Vous verrez qu'il existe ici un seul fichier modifié disponible pour commit, ViewController.m, et les nouveaux ajouts sont mis en surbrillance comme d'habitude.

Ajoutez le message de commit « Premier commit d'une nouvelle branche... », puis cliquez sur le bouton Commit 1 File. Les changements sont effectués dans la branche AnotherBranch.

Ouvrez l'éditeur de versions (menu View > Version Editor > Show Version Editor) et allez dans la barre d'outils en dessous du volet de droite. Vous verrez que la branche sélectionnée est AnotherBranch. Cliquez dessus et vous verrez apparaître les deux branches, celle-ci et la branche master. Sélectionnez n'importe quelle révision dans la branche master et Xcode mettra en évidence les changements entre la version actuelle d'AnotherBranch et la révision sélectionnée. Cette fonctionnalité, ainsi que tout ce dont nous avons parlé dans la section Comparer les versionsComparer les versions du tutoriel, vous permet de suivre facilement les modifications du code effectuées parmi toutes les branches de votre projet.

Enfin, pour passer à une autre branche ou à la branche master, allez au menu Source Control > GitDemo - AnotherBranch > Switch to Branch :

Sélectionnez la branche à laquelle vous souhaitez passer dans la fenêtre qui apparaît, dans notre cas, la branche master :

Sélectionnez-la et cliquez sur le bouton Switch. Master redeviendra la branche active et vous remarquerez que toutes les modifications apportées à la branche AnotherBranch n'apparaissent pas ici. C'est très bien, car nous avons réussi à faire évoluer notre projet sans modifier sa version stable.

C'est toujours une bonne pratique de travailler sur d'autres branches que la branche master dans le stade de développement. Cependant, tous les ajouts ou modifications du code doivent être rassemblées dans la branche master si elles sont censées exister dans une prochaine version de l'application, alors dans cette partie nous allons voir comment cela peut se faire. Comme vous pouvez le déduire du titre de la section, la fonctionnalité dont nous allons parler ici est appelée fusion et Xcode fournit un moyen rapide de fusionner les révisions de deux branches en une seule.

Faisons un petit test pour voir comment fonctionne la fusion. Tout d'abord, assurez-vous que vous êtes en train de travailler sur la branche master. Si ce n'est pas le cas, allez au menu AnotherBranch > Switch To Branch et dans la fenêtre qui s'ouvre, sélectionnez la branche master.

Ensuite, créez une nouvelle branche à l'aide du menu Source Control > GitDemo - master > New Branch, et nommez-la LastBranch.

Donnez à Xcode quelques secondes pour la préparer. Maintenant, ouvrez le fichier ViewController.m pour créer une autre méthode privée factice et commencez par la déclarer :

@interface ViewController ()

 ...


-(void)sayByeBye;

@end

Puis ajoutez son implémentation :

-(void)sayByeBye{
     NSLog("Bye - Bye");
}

Et puis appelez-la dans la méthode viewDidLoad :

- (void)viewDidLoad
{
     ...    

     [self sayByeBye];
}

Avant la fusion, les modifications apportées à cette branche doivent d'abord être enregistrées dans le référentiel local. Par conséquent, allez dans Source Control > Commit pour effectuer le commit.

Faisons le point. Pour fusionner deux branches différentes en une seule, vous avez deux options :

1. Merge From Branch : toutes les modifications présentes dans la branche choisie seront fusionnées à la branche où vous travaillez actuellement ;
2. Merge Into Branch : toutes les modifications présentes dans la branche où vous travaillez actuellement seront fusionnées à la branche de votre choix.
   Ces deux options se trouvent dans le menu Source Control > GitDemo. Notez que lorsque votre branche active est master, la deuxième option n'est pas disponible.

Supposons maintenant qu'un développeur a travaillé sur la branche AnotherBranch créée précédemment, où nous avons implémenté la méthode sayHello, et un autre a travaillé sur LastBranch et a mis en œuvre la méthode sayByeBye, et vous devez inclure ces deux nouveaux ajouts à la prochaine version stable de l'application. Qu'allez-vous faire ? Simplement, tout en ayant la branche master active, vous allez fusionner les deux autres branches comme suit.

Dans un premier temps, assurez-vous que vous travaillez sur la branche master, si ce n'est pas le cas allez à celle-ci.

Ensuite, ouvrez Source Control > GitDemo - master > Merge From Branch et dans la fenêtre qui s'ouvre, sélectionnez la branche AnotherBranch et cliquez sur le bouton Merge.

Une fenêtre de comparaison de révision apparaîtra et vous pourrez prévisualiser toutes les modifications qui seront apportées au code après la fusion. Si vous voulez, regardez rapidement et lorsque vous êtes prêt, cliquez encore une fois sur le bouton Merge.

Lorsque Xcode vous demande si vous voulez prendre des instantanés du projet, cliquez sur le bouton Enable pour continuer. Patientez quelques instants et voilà ! Maintenant, les modifications apportées à la branche AnotherBranch ont été fusionnées dans la branche master.

Procédez de la même façon pour la fusion à partir de la branche LastBranch. Vous remarquerez que Xcode ne vous permettra pas d'effectuer une nouvelle fusion si vous n'enregistrez pas la version actuelle du fichier modifié. Donc, il faut faire commit. Faites-le et puis réessayez la fusion de LastBranch. Dans la fenêtre de comparaison de versions, vous pouvez voir une zone rouge indiquant les changements après la fusion, au lieu de la bleue habituelle. Cela signifie que le code existant dans la branche que vous fusionnez remplacera le code existant sur les mêmes lignes de la branche de travail actuelle, master, comme indiqué ci-dessous :

Vous pouvez facilement éviter cela et garder tant le code existant que le nouveau, si vous utilisez les boutons situés sur la barre d'outils, en dessous des volets de l'éditeur. Après avoir sélectionné les lignes de code en cliquant sur la forme arrondie indiquée ci-dessus par une flèche, utilisez tous les boutons pour voir les options disponibles. Dans la capture d'écran suivante, j'en ai choisi la première, ce qui signifie que les lignes de code de la branche master seront placées en ordre avant le code de l'autre branche :

Passez par toutes les options et assurez-vous qu'aucune ligne de code, d'aucune branche, ne sera exclue. Une fois que vous avez terminé et que vous êtes sûr que tout le code est là, cliquez sur le bouton Merge.

Félicitations ! Vous avez réussi à fusionner avec succès le code de plusieurs branches en une seule, et maintenant vous savez comment gérer des cas similaires avec Xcode.

L'option d'annuler les modifications indésirables apportées au code d'un projet est très utile, car avec un simple clic vous pouvez annuler tout le travail fait depuis le dernier commit. Cela peut servir lorsque l'implémentation n'évolue pas dans la direction souhaitée et que vous voulez recommencer depuis la dernière version stable et fonctionnelle. Notez cependant que l'annulation des changements est une opération irréversible, donc si vous le faites accidentellement, vous n'aurez aucune chance de récupérer votre travail. Alors, soyez prudent.

Tout à l'heure, quand nous discutions sur la comparaison des versions, nous avons vu pour la première fois comment défaire certaines modifications du code à l'aide du menu de la petite icône située à côté de chaque zone marquée, entre les volets de l'éditeur. Ici, nous allons voir comment revenir en arrière sur l'ensemble d'un projet et retourner instantanément au dernier commit.

Afin de tester cela, ouvrez le fichier ViewController.h et ajoutez la déclaration d'une méthode publique :

@interface ViewController : UIViewController

-(void)aVeryCoolMethod;

@end

Maintenant, modifions un peu le fichier ViewController.m en ajoutant une petite implémentation pour cette méthode :

-(void)aVeryCoolMethod{
     NSLog("I'm feeling that you'll discard me... Really?");
}

Remarquez dans le navigateur de projet que la lettre M a été ajoutée à côté des deux fichiers que nous venons de modifier. C'est bien, car nous voulons voir si en annulant les changements, tous les fichiers modifiés seront concernés et reviendront à leur état précédent.

Permettez-moi de mentionner ici un détail important : vous pouvez annuler tant les modifications apportées à tous les fichiers que celles d'un fichier en particulier. C'est à vous de choisir et si vous voulez le faire sélectivement, d'abord assurez-vous de choisir les fichiers dont vous souhaitez annuler les modifications. Pour être plus précis : si vous sélectionnez uniquement le fichier ViewController.m et puis ouvrez le menu Source Control, vous trouverez une option intitulée Discard Changes in ViewController.m. De même, si vous sélectionnez uniquement le fichier ViewController.h et que vous ouvrez le même menu, vous verrez cette fois l'option Discard Changes in ViewController.h. Toutefois, si vous souhaitez annuler les modifications dans les deux fichiers (et nous pouvons supposer qu'il pourrait y en avoir plus que deux), il suffit de les sélectionner dans le navigateur de projet et d'ouvrir à nouveau Source Control. La commande respective se transforme en Discard Changes in 2 Files, comme indiqué ci-dessous :

Dans cet exemple, nous n'allons pas utiliser cette option, mais Discard All Changes. En cliquant dessus, un message de confirmation apparaît sur l'écran, et c'est le seul et unique effort fait par Xcode pour éviter que cela arrive accidentellement.

Cliquez sur le bouton Discard All Changes... et la méthode publique appartient désormais au passé. Comme vous voyez, l'annulation de tous les changements se trouve à quelques clics de votre état actuel. Alors je vous conseille une fois de plus d'être extrêmement prudent lorsque vous êtes sur le point d'annuler les modifications, ainsi que lorsque vous utilisez le menu Source Control en général.

Au long de ce tutoriel, j'ai fait l'effort de présenter de manière approfondie et détaillée la façon de gérer le contrôle de versions des sources en utilisant Xcode. Dans les coulisses, le vrai travail est fait par git, l'un des systèmes de contrôle de versions les plus populaires et les plus utilisés. Vous avez peut-être remarqué qu'aucune référence n'a été faite à GitHub ou à l'une de ses caractéristiques liées à Xcode. Cela a été fait exprès, car mon objectif était de me concentrer entièrement sur la façon dont Xcode gère git, et d'ailleurs GitHub peut être utilisé uniquement si vous savez comment utiliser le contrôle de versions. En plus de cela et comme je l'ai déjà mentionné au début de ce tutoriel, si vous êtes un membre d'une équipe, travailler avec un système de contrôle de versions est obligatoire. Si vous travaillez seul, je vous encourage et vous invite à commencer à utiliser le contrôle de versions avec Xcode si vous ne le faites pas déjà. C'est un moyen de garantir que vous n'allez pas ruiner tout votre travail effectué avec tant d'efforts et des dépenses, et en plus de cela, ce sera plus facile de faire évoluer vos applications lors de l'ajout de nouvelles fonctionnalités. Pour terminer, je voudrais que les exemples présentés ici vous soient utiles, et que l'utilisation du contrôle de versions de Xcode réussisse à vous épargner finalement quelques heures de travail.

Comme toujours, n'hésitez pas à partager vos pensées en laissant un commentaire sur la page de l'article original.

Nous remercions, Simon ng, de nous avoir aimablement autorisés à publier son article. Cet article est une traduction autorisée dont le texte original peut être trouvé sur appcoda.com. Nous remercions aussi Mishulyna pour sa traduction, LeBzul pour sa relecture technique ainsi que ClaudeLELOUP pour sa relecture orthographique.

Les commentaires et les suggestions d'amélioration sont les bienvenus, alors, après votre lecture, n'hésitez pas. Commentez.