GitHub Desktop est disponible sur deux systèmes de bureau, Windows et macOS, d’après la documentation officielle sur ses plateformes. Cela permet de faire passer un projet entre les deux, à condition d’utiliser le dépôt GitHub comme point de remise : il faut publier les changements depuis un ordinateur, puis les récupérer sur l’autre. GitHub Desktop ne transforme pas le dépôt en dossier synchronisé automatiquement et ne permet pas d’exécuter Xcode directement sous Windows.
Convient : aux étudiants qui écrivent ou relisent du code sur Windows et doivent ensuite ouvrir leur projet dans Xcode sur un Mac distant.
Ne convient pas : à ceux qui veulent lancer Xcode sous Windows ou retrouver automatiquement des fichiers qui n’ont jamais été enregistrés et publiés.
Cette procédure s’adresse aux personnes qui commencent SwiftUI sans disposer d’un Mac personnel.
Elle concerne aussi les étudiants qui ont déjà un dépôt de cours et veulent conserver une trace claire des échanges entre deux ordinateurs.
Elle peut enfin servir sur un ordinateur scolaire ou emprunté, lorsque la copie manuelle des fichiers n’est pas une option pratique.
00Le dépôt comme carnet de passation
Un dépôt Git enregistre des versions successives d’un projet. Pour cet usage, imaginez un cahier de liaison : Windows y inscrit une étape terminée, le Mac distant la récupère, puis le Mac y inscrit à son tour son travail. Les fichiers ne passent pas directement d’un ordinateur à l’autre ; le dépôt hébergé entre les deux joue le rôle de point de remise.
Dans GitHub Desktop, un commit correspond à un groupe de modifications enregistré dans l’historique. Le push publie ce groupe sur le dépôt distant. Sur l’autre ordinateur, une opération de synchronisation permet de récupérer les changements disponibles. La documentation de GitHub explique ces actions dans les pages consacrées à la publication des changements et à la synchronisation d’une branche.
| Action | Ce qui se passe | Ce qui ne se passe pas |
|---|---|---|
| Enregistrer un fichier | Le fichier modifié est écrit sur l’ordinateur utilisé. | Le dépôt distant n’est pas mis à jour pour autant. |
| Créer un commit | Une étape de travail est ajoutée à l’historique local du dépôt. | Le commit n’est pas nécessairement publié en ligne. |
| Publier les changements | Les commits locaux sont envoyés au dépôt distant. | Le Mac distant ne récupère pas automatiquement les fichiers. |
| Récupérer les changements | L’ordinateur consulte ou reçoit les changements publiés sur le dépôt. | Les modifications locales non enregistrées ne sont pas sauvegardées par cette action. |
Un autre point à vérifier avant de commencer concerne l’accès au dépôt. Si le cours utilise un dépôt privé, le compte employé sur chaque ordinateur doit disposer des droits nécessaires. GitHub distingue plusieurs niveaux d’autorisation sur un dépôt personnel ; consultez les règles officielles de partage et de permission ou demandez au responsable du cours de vérifier l’accès avant la séance.
01Préparer Windows et publier une étape
Avant de modifier le projet, repérez son dépôt et vérifiez que GitHub Desktop l’ouvre correctement. Si le dépôt n’est pas encore présent sur l’ordinateur, clonez-le depuis GitHub Desktop : le clonage crée une copie de travail locale reliée au dépôt distant. Si le projet se trouve déjà sur l’ordinateur, assurez-vous qu’il s’agit bien de la copie associée au dépôt de cours, et non d’une autre version portant un nom proche.
Voici le parcours pour remettre une étape de travail depuis Windows :
- Ouvrez le dépôt dans GitHub Desktop et vérifiez que le nom affiché correspond au projet du cours.
- Ouvrez les fichiers concernés dans l’éditeur utilisé pour le cours. Si vous modifiez du code, enregistrez chaque fichier avant de revenir à GitHub Desktop.
- Examinez la liste des changements. Elle permet de repérer les fichiers modifiés ou ajoutés et d’éviter d’inclure par inadvertance un document personnel ou un fichier qui ne concerne pas le devoir.
- Sélectionnez les modifications destinées à cette étape et rédigez un résumé explicite du commit, par exemple « Ajout de l’écran de profil ».
- Créez le commit, puis publiez les changements vers le dépôt distant. La documentation de GitHub décrit cette étape de publication depuis GitHub Desktop ; l’action n’est pas équivalente au simple fait d’enregistrer votre code.
- Vérifiez que le dépôt affiche bien les changements attendus avant de changer d’ordinateur.
Le tableau suivant aide à déterminer si le travail est prêt à passer sur le Mac. Il ne s’agit pas d’une règle sur les fichiers à inclure dans tous les cours : les consignes de l’enseignant et les dépendances du projet priment.
| Élément à vérifier sur Windows | Prêt à transmettre si… | À examiner avant publication si… |
|---|---|---|
| Code source | Les modifications voulues apparaissent dans la liste des changements. | Un fichier attendu n’apparaît pas ou le changement semble incomplet. |
| Fichiers du projet | Les fichiers nécessaires au cours figurent dans le dépôt, conformément aux consignes. | Un fichier de projet a été déplacé, supprimé ou n’est pas suivi. |
| Résumé du commit | Il décrit l’étape réellement effectuée. | Il ne permet pas de distinguer cette remise des précédentes. |
| Informations sensibles | Aucun secret n’est ajouté au dépôt. | Un mot de passe, jeton ou fichier de clé apparaît dans les changements. |
| Publication | Le dépôt distant contient le commit destiné au Mac. | Le travail existe seulement sur l’ordinateur Windows. |
Cette dernière vérification évite une confusion fréquente : un commit conservé uniquement sur Windows n’est pas disponible sur le Mac. Si vous ne voyez pas l’action de publication attendue ou si une erreur apparaît, vérifiez d’abord que le compte utilisé a accès au dépôt et que les changements sont bien enregistrés.
02Ouvrir le projet sur le Mac distant
Sur le Mac distant, la première étape dépend de l’existence d’une copie locale du projet. Si le projet n’a jamais été ouvert sur ce Mac, clonez le dépôt avec GitHub Desktop. Si une copie s’y trouve déjà, ouvrez cette copie et récupérez les changements publiés depuis Windows avant de commencer à modifier des fichiers.
Apple documente la gestion des dépôts Git dans Xcode : un projet peut être associé à un dépôt de contrôle de versions et ses changements peuvent être suivis dans cet environnement. Cette relation entre le dépôt et le projet est décrite dans les pages Apple sur la configuration du contrôle de versions d’un projet Xcode et la gestion du code source dans Xcode. Le dépôt facilite donc le passage des fichiers du projet ; il ne garantit pas à lui seul que le projet satisfera toutes les exigences du cours.
Pour reprendre le travail :
- Ouvrez GitHub Desktop sur le Mac et choisissez le dépôt du cours, ou clonez-le s’il n’est pas présent.
- Récupérez les changements publiés depuis Windows avant toute modification locale.
- Dans le dossier du dépôt, repérez le fichier de projet ou l’espace de travail indiqué par l’enseignant.
- Ouvrez ce fichier dans Xcode et vérifiez que les fichiers du cours attendus sont visibles.
- Si le cours demande une vérification, lancez l’action demandée et notez toute erreur utile à corriger.
L’objectif d’acceptation de cette passation est modeste mais vérifiable : le dépôt correct s’ouvre dans Xcode et les fichiers du cours sont présents. Un projet qui s’ouvre n’est pas forcément déjà prêt à être remis : il peut rester à corriger des erreurs, à retrouver une dépendance ou à respecter une consigne propre au cours. Il vaut mieux séparer ces problèmes de configuration du simple transfert des changements.
03Reprendre le travail sur Windows sans écraser la version distante
Après une séance sur le Mac, ne revenez pas directement au code sous Windows comme si les deux copies s’étaient mises à jour. Sur le Mac, enregistrez vos fichiers, examinez la liste des changements dans GitHub Desktop, créez un commit puis publiez-le. Ensuite, sur Windows, ouvrez le même dépôt et récupérez les changements publiés avant de reprendre le travail.
Si personne n’a modifié la même partie du projet entre-temps, la récupération peut s’effectuer sans conflit. En revanche, si Windows et le Mac ont tous deux modifié la même zone d’un fichier, Git peut demander de réunir ces changements. L’aide d’Apple sur la combinaison des changements dans un dépôt de contrôle de versions explique le principe de résolution dans Xcode. Le point important est de lire les deux versions concernées au lieu de choisir rapidement celle qui semble la plus récente.
En cas de conflit, procédez avec prudence :
- Arrêtez les modifications dans le fichier signalé jusqu’à ce que les deux versions aient été examinées.
- Repérez les lignes venant de Windows et celles créées sur le Mac.
- Conservez ou réécrivez le code de façon à inclure le travail attendu des deux côtés.
- Vérifiez le résultat dans le projet, puis enregistrez et publiez la résolution.
- Sur l’autre ordinateur, récupérez à nouveau la version publiée avant de continuer.
Évitez surtout de remplacer le dossier local par une copie récupérée sans vérifier ce qui n’a pas encore été publié. Cela peut supprimer des changements qui n’existent que sur un seul ordinateur. Pour un devoir, un message de commit explicite et une vérification avant chaque changement de poste rendent le retour en arrière et la discussion avec l’enseignant plus faciles.
04Fichiers du projet et contrôle de sécurité
Tous les fichiers visibles dans le dossier d’un projet ne sont pas nécessairement utiles dans le dépôt. Les sources et les éléments indispensables à l’ouverture du projet doivent être traités selon les consignes du cours ; certains fichiers générés ou réglages propres à un ordinateur peuvent être exclus. Mais appliquer une règle générale sans connaître les dépendances du projet peut aussi empêcher un camarade ou un enseignant d’ouvrir correctement la remise.
GitHub explique comment ignorer des fichiers avec Git et propose un modèle d’exclusion destiné aux projets Swift. Utilisez ces ressources pour identifier les catégories souvent exclues, puis vérifiez chaque décision avec le projet concerné et les consignes de l’enseignant. Un fichier non suivi parce qu’il est ignoré ne sera pas publié par le simple fait de créer un commit.
La sécurité demande une vérification distincte. Ne placez jamais dans le dépôt un mot de passe, un jeton d’accès, une clé privée ou une autre information permettant d’ouvrir un compte ou un service. Si une information sensible a déjà été publiée, la supprimer dans une modification ultérieure ne suffit pas nécessairement à la retirer de l’historique ; suivez les indications de GitHub pour retirer des données sensibles d’un dépôt.
Avant de changer d’ordinateur, cochez les éléments applicables :
- [ ] Le bon dépôt de cours est ouvert sur l’ordinateur utilisé.
- [ ] Les fichiers modifiés sont enregistrés et visibles dans la liste des changements.
- [ ] Le commit décrit le travail remis, et les changements ont été publiés.
- [ ] Sur l’autre ordinateur, les changements ont été récupérés avant de reprendre le code.
- [ ] Le projet et les fichiers demandés par le cours sont présents.
- [ ] Aucun mot de passe, jeton ou fichier de clé n’a été inclus.
- [ ] Tout conflit a été lu et résolu sans supprimer les modifications d’un côté.
05Questions fréquentes sur le passage entre ordinateurs
GitHub Desktop envoie-t-il automatiquement le projet Windows au Mac distant ?
Non. Il faut publier les changements depuis Windows, puis les récupérer sur le Mac. Les fichiers non enregistrés ou les modifications non publiées restent sur l’ordinateur où ils se trouvent.
Comment continuer sur le Mac distant un projet iOS modifié sous Windows ?
Publiez un commit depuis Windows, puis ouvrez le même dépôt sur le Mac distant et récupérez les changements. Ouvrez ensuite le fichier de projet ou l’espace de travail dans Xcode, puis vérifiez la présence des fichiers exigés pour le cours.
Comment retrouver sous Windows le code modifié sur le Mac distant ?
Enregistrez, commitez et publiez les changements depuis le Mac. Sur Windows, récupérez la version publiée avant de modifier à nouveau les fichiers. En présence d’un conflit, comparez les deux versions au lieu d’écraser l’une d’elles.
Quels fichiers éviter de publier avec un projet Xcode ?
Excluez toujours les secrets, notamment les mots de passe, jetons et clés privées. Pour les fichiers générés ou propres à une machine, vérifiez les consignes du cours, les besoins du projet et les règles d’exclusion Swift avant de décider.
06Choisir un environnement pour la suite du cours
GitHub Desktop organise le passage des versions entre Windows et un Mac, mais ne remplace pas le Mac nécessaire pour ouvrir Xcode. Si le cours exige uniquement de lire ou modifier des fichiers compatibles avec Windows, le PC existant peut suffire. Si l’évaluation nécessite réellement Xcode, le dépôt fournit une méthode de transfert, mais il faut aussi pouvoir accéder à un environnement macOS.
Un Mac acheté peut convenir à un usage régulier et durable, tandis qu’un ordinateur déjà disponible reste le choix le plus simple si le cours n’impose pas Xcode. Pour une séance de validation ou une période d’apprentissage limitée, un Mac distant évite l’achat immédiat, mais suppose une connexion réseau, la gestion des accès au dépôt et le temps nécessaire pour ouvrir le projet et en vérifier l’état. NUKCLOUD présente son accès à un Mac distant ; les étudiants qui souhaitent comprendre les modalités d’accès peuvent également consulter la page d’aide.
Le flux de travail reste le même, quel que soit l’environnement retenu : enregistrer, examiner, commiter, publier, puis récupérer avant de reprendre ailleurs. Cette discipline évite les fichiers manquants et les versions divergentes ; elle ne dispense ni de vérifier les consignes du cours, ni de protéger les informations sensibles.