Dans un précédent billet de blog, nous vous avons présenté Git (un système de contrôle de version) et Github (un service d’hébergement basé sur le cloud) et comment vous pouvez partager votre code 4D avec d’autres développeurs. Dans ce billet de blog, nous allons aller un peu plus loin en explorant certains scénarios qu’un développeur peut rencontrer, comme le clonage d’un dépôt distant, l’ignorance des fichiers déjà livrés et la résolution des conflits de fusion.
Conditions préalables
Avant d’aller plus loin, nous supposons que vous savez comment créer une base de données de projet ou convertir une base de données binaire en projet. Avoir Git installé sur votre machine et un compte sur Github sont obligatoires. Si vous ne les avez pas encore, veuillez vous référer à cet article de blog pour savoir comment procéder.
Cloner un dépôt distant
Il est temps de reprendre le travail sur notre application. Mais pour une raison quelconque, vous n’avez pas le projet sur lequel nous avons travaillé la dernière fois sur votre machine. Que faire ?
Depuis que nous avons créé un dépôt sur GitHub(article de blog précédent), il existe en tant que dépôt distant. Nous devons maintenant créer une copie locale sur notre machine et effectuer une synchronisation entre les deux emplacements. Comment procéder ?
- Connectez-vous à votre compte Github,
- Naviguez vers la page principale du dépôt,
- Cliquez sur le bouton« Cloner ou télécharger« , puis cliquez sur l’icône du presse-papiers (comme indiqué dans l’image ci-dessous) :
- Ouvrez un terminal et indiquez l’emplacement où vous souhaitez cloner le répertoire.
- Tapez git clone et collez l’URL que vous avez copié à l’étape 3.
Félicitations ! Vous avez créé une copie locale sur votre machine.
gitignore
Je ne veux pas que git suive un fichier ou un dossier particulier
Parfois, nous avons des fichiers ou des répertoires dans notre projet que nous ne voulons pas suivre. C’est là qu’un fichier .gitignore est utile. Comme son nom l’indique, il indique à Git les fichiers, répertoires ou motifs à ignorer dans le référentiel.
Dans notre cas, nous voulons que Git ignore le dossier Data (qui contient le journal, les préférences, .4dd, et le dossier DerivedData ).
- Créer .gitignore
- Configuration des fichiers/dossiers ignorés
.gitignore utilise des motifs de globbing pour comparer les noms de fichiers. Vous pouvez construire vos modèles en utilisant divers symboles. Par exemple, pour ignorer un dossier, nous ajoutons un slash à la fin du nom du dossier. Vous pouvez vous référer à cet article pour en savoir plus sur les modèles .gitignore.
Ignorer les fichiers qui ont déjà été livrés au référentiel
Gardez à l’esprit que lorsque vous créez un nouveau référentiel, vous devez également créer un fichier .gitignore pour tous les modèles de fichiers que vous souhaitez ignorer. Cependant, il arrive que des fichiers se glissent entre les mailles du filet et que vous souhaitiez les ignorer par la suite.
Pas de panique ! En quelques étapes simples, vous pouvez nettoyer votre référentiel et vous assurer que ces éléments sont ignorés :
- Préparez les fichiers pour la suppression, mais laissez-les localement : git rm -r –cached
- Inspectez l’ensemble du répertoire de travail à la recherche de tout fichier nouveau, supprimé ou modifié et ajoutez-le à l’index : git add
- Envoyez les fichiers de la zone de transit vers le dépôt local : git commit -m « Nettoyer les fichiers ignorés ».
- Envoyer les changements au dépôt distant : git push
Voilà ! Vous pouvez vérifier dans le dépôt distant et que les fichiers ne sont pas là !
Note importante: Les fichiers ignorés restent dans l’historique du dépôt. C’est pourquoi, lorsque vous créez de nouveaux dépôts, vous devez également créer des fichiers .gitignore indiquant tous les fichiers, dossiers ou modèles que vous souhaitez ignorer. Sinon, si vous ne voulez pas que certains fichiers soient conservés dans l’historique, vous devrez supprimer le dépôt de Github et le pousser à nouveau.
Comment résoudre les conflits de fusion
Tout d’abord, RESTEZ CALME !
Lorsque plusieurs développeurs travaillent dans le même système de contrôle de version, la gestion d’éventuels conflits devient une tâche quotidienne. Plusieurs options sont disponibles. Le conflit peut être facilement résolu à l’aide de l’éditeur 4D, mais comme tous les fichiers sont maintenant au format texte, vous pouvez également utiliser un éditeur de texte pour résoudre manuellement les conflits. De plus, il existe de nombreux outils de fusion qui peuvent être intégrés à GIT. Dans l’exemple ci-dessous, nous utilisons l’éditeur 4D pour résoudre les conflits.
Examinons un conflit à l’aide de la méthode 4D. Pour ce faire, il est nécessaire de simuler un utilisateur secondaire / dépôt git local en dupliquant le dossier de la base de données et en s’assurant qu’il possède au moins une méthode de projet. Maintenant il y a deux dossiers de base de données : my4DApplication et my4DApplication2. Ensuite, ouvrez les deux applications.
-
- Ouvrez la méthode de projet dans la première application, et ajoutez du contenu (un commentaire, par exemple).
- Si vous exécutez git status, les changements dans la méthode seront détectés. Validez et poussez les nouveaux changements.
- Scénario : quelqu’un d’autre modifie la même méthode, au même moment . Simulons cela en ouvrant la même méthode dans la deuxième application et en la modifiant avec un commentaire différent.
- Commit et push les nouveaux changements. Comme vous pouvez le voir, le push est rejeté et un pull est suggéré à la place :
- L’exécution du pull git suggéré n’aide pas :
- Ouvrez la méthode de projet dans la première application, et ajoutez du contenu (un commentaire, par exemple).
Que faire maintenant ?
Ouvrez la méthode avec le conflit. La ligne avec Head indique les changements locaux et la ligne en rouge indique le numéro du commit fait par l’autre utilisateur.
Résoudre le conflit est facile, il suffit de sélectionner les bonnes parties du code et de pousser les changements. Dans ce cas, je garde les deux messages ALERT avec des commentaires différents :
Une fois que c’est fait, l’autre utilisateur peut exécuter git pull pour obtenir les nouveaux changements. Les deux utilisateurs ont maintenant le même contenu dans la méthode.
Pour éviter les conflits en premier lieu
Il n’existe pas de méthode infaillible pour éviter les conflits à tout moment, mais l’exécution de git fetch peut vous éviter bien des maux de tête liés à la fusion. Il vérifie si le dépôt distant a de nouveaux commits. Ne pas le faire avant d’essayer de pousser a causé l’erreur [Rejected].
Pour conclure
Dans cet article, nous avons abordé différents scénarios qu’un développeur est susceptible de rencontrer lorsqu’il travaille avec Git. Dans un prochain article, nous nous éloignerons de la ligne de commande et vous montrerons comment utiliser un client GUI pour travailler avec Git.