Wie setzt man mit GitHub Desktop Aufgaben zwischen Windows und einem Remote-Mac fort? Studierenden-Tutorial 2026

GitHub Desktop ist die Bedienoberfläche für Änderungen an einem Git-Repository. Das Repository ist dabei eher ein versioniertes Aufgabenheft als ein gemeinsamer Live-Ordner: Ein Commit hält einen geprüften Zwischenstand fest, ein Push überträgt diesen Stand zum entfernten Repository, und ein Abruf aktualisiert die lokale Kopie. Die offiziellen Erläuterungen zu Push-Vorgängen in GitHub Desktop und zur Synchronisierung eines Branches unterscheiden diese Arbeitsschritte.

Das ist wichtig, weil „auf dem Rechner gespeichert“ nicht dasselbe bedeutet wie „an den anderen Rechner übergeben“. Eine Datei kann lokal vorhanden sein, aber noch nicht committet oder gepusht worden sein. Umgekehrt kann auf dem Remote-Mac ein neuer Stand liegen, während der Windows-Rechner noch eine ältere Arbeitskopie zeigt. Erst die kontrollierte Abfolge macht sichtbar, welcher Stand wo verfügbar ist.

Vor dem Start muss feststehen, welches Repository für die Abgabe verwendet wird und ob das verwendete Konto darauf zugreifen darf. Bei einem persönlichen Repository hängen mögliche Aktionen von der vergebenen Rolle ab; die GitHub-Dokumentation zu Repository-Berechtigungen beschreibt diese Unterschiede. Ist das Kursprojekt nur lesbar, lässt sich zwar der Code beziehen, aber nicht ohne Weiteres in dasselbe Repository zurückpushen. Dann ist zuerst mit der Lehrkraft oder der zuständigen Person zu klären, welcher Abgabeweg vorgesehen ist.

Klären Sie zuerst, ob der Kurs bereits ein Repository bereitstellt oder ob ein persönliches Repository erstellt werden soll. Bei einem bestehenden Kursprojekt ist dessen vorgegebene Struktur maßgeblich. Legen Sie nicht vorschnell ein zweites Repository an: Dadurch können Abgabeadresse, Branch oder Projektdateien auseinanderlaufen. Bei einem neuen Projekt sollte der Repository-Name eindeutig zum Kurs passen, ohne vertrauliche Angaben wie Zugangsdaten oder persönliche Kennungen zu enthalten.

Öffnen Sie das Repository auf Windows in GitHub Desktop. Ist es noch nicht auf diesem Rechner vorhanden, verwenden Sie die Klonfunktion und wählen einen Speicherort, auf den Ihr Benutzerkonto zugreifen kann. Der gewählte Ordner sollte sich leicht wiederfinden lassen und nicht in einem temporären Download-Verzeichnis liegen. Ein Klon erstellt eine lokale Arbeitskopie; er ist nicht selbst die Sicherung der jeweils neuesten Fassung.

Prüfen Sie anschließend, ob der erwartete Branch ausgewählt ist und ob die Projektdateien angezeigt werden. Falls die Lehrkraft einen bestimmten Branch, Ordnernamen oder Abgabeweg vorgibt, richten Sie sich danach. Bei fehlendem Zugriff ist es sicherer, die Berechtigung zu klären, als ein fremdes Konto zu verwenden oder Repository-Dateien über einen privaten Umweg zu verteilen.

Schreiben Sie auf Windows zunächst nur die Änderungen, die dort sinnvoll überprüft werden können. Bei einem SwiftUI-Projekt können dazu etwa Quellcodedateien, Kommentare oder Aufgabenbeschreibungen gehören. Windows kann dadurch zwar den Codebestand vorbereiten, aber nicht die Ausführung in Xcode ersetzen. Der Wechsel auf den Remote-Mac ist nötig, sobald die Aufgabe eine macOS-Entwicklungsumgebung, Xcode oder eine dortige Projektprüfung verlangt.

Bevor Sie den Rechner wechseln, öffnen Sie in GitHub Desktop die Änderungsansicht. Lesen Sie die Liste Datei für Datei durch, statt alle angezeigten Änderungen ungeprüft zu übernehmen. Eine unerwartet geänderte Datei kann auf einen falschen Projektordner, automatische Formatierung oder eine lokale Einstellung hindeuten. Entfernen Sie versehentliche Änderungen, bevor Sie einen Commit erstellen.

Formulieren Sie eine kurze Commit-Nachricht, die den erledigten Arbeitsschritt beschreibt, zum Beispiel „Ansicht für Kursaufgabe ergänzt“. Eine verständliche Nachricht hilft später, den eigenen Zwischenstand von Änderungen auf dem Mac zu unterscheiden. Der Commit speichert einen nachvollziehbaren Zustand im lokalen Repository; er ist noch keine Garantie, dass der Remote-Mac ihn bereits abrufen kann.

Führen Sie danach den Push aus und warten Sie, bis GitHub Desktop den Vorgang abgeschlossen meldet. Der Push überträgt die lokalen Commits an das Remote-Repository. Wird stattdessen ein Hinweis auf Remote-Änderungen angezeigt, synchronisieren Sie zuerst und lesen Sie die angezeigte Meldung, anstatt den Vorgang zu erzwingen oder Dateien zu überschreiben.

Auf dem Remote-Mac muss dasselbe Repository geöffnet werden. Ist es dort noch nicht vorhanden, klonen Sie es in einen gut auffindbaren Arbeitsordner. Gibt es bereits eine Arbeitskopie, prüfen Sie vor der Bearbeitung, ob der richtige Branch ausgewählt ist, und rufen Sie den aktuellen Stand ab. Eine erneute Klonaktion ist nicht nötig, wenn die passende lokale Kopie bereits existiert.

Öffnen Sie das Kursprojekt anschließend über die von der Lehrkraft vorgesehene Projektdatei. Prüfen Sie im Projektfenster von Xcode, ob die erwarteten Gruppen und Quellcodedateien vorhanden sind und ob die richtige Projektfassung geladen wurde. Apple beschreibt, wie ein Xcode-Projekt für die Arbeit mit Versionsverwaltung eingerichtet wird; die Erläuterungen zur Quellcodeverwaltung in Xcode helfen, Repository und Projektarbeit auseinanderzuhalten.

Als erste Abnahme genügt in diesem Übergabeschritt, dass Xcode das richtige Projekt öffnet und die für die Aufgabe relevanten Dateien auffindbar sind. Wenn das Projekt nicht wie erwartet erscheint, prüfen Sie zuerst Ordner, Branch und Projektdatei. Ein fehlendes oder falsch geöffnetes Projekt sollte nicht durch zusätzliche, unkoordinierte Kopien „repariert“ werden.

Bearbeiten Sie das Projekt in Xcode und speichern Sie die Änderungen. Bevor Sie die Arbeit beenden, kontrollieren Sie in der Versionsverwaltungsansicht, welche Dateien geändert oder neu angelegt wurden. Xcode kann Git-Funktionen für Projektänderungen anzeigen. Entscheidend bleibt, dass die Änderungsliste tatsächlich zum geplanten Arbeitsschritt passt.

Erstellen Sie den Commit erst nach dieser Kontrolle und pushen Sie ihn anschließend zum Repository. Lassen Sie die Arbeitskopie geöffnet, bis der Push sichtbar abgeschlossen ist. Ein geschlossenes Fenster oder eine erfolgreiche Projektsitzung beweist nicht, dass der neue Code übertragen wurde. Wenn der Push wegen Änderungen auf dem Remote-Repository nicht möglich ist, synchronisieren Sie nach Anzeige der Unterschiede und lösen Sie die Ursache, statt lokale Änderungen durch einen erzwungenen Vorgang zu verdrängen.

Kehren Sie dann zu Windows zurück und synchronisieren Sie denselben Branch in GitHub Desktop. Prüfen Sie die neu eingegangenen Änderungen, bevor Sie weiterarbeiten. Die Reihenfolge ist wichtig: Zuerst den Remote-Stand abrufen, dann lokale Arbeit darauf fortsetzen. Werden beide Arbeitskopien unabhängig voneinander verändert, kann Git bei Änderungen an denselben Codezeilen einen Konflikt erkennen. In diesem Fall müssen die betroffenen Fassungen verglichen und zusammengeführt werden; Apple beschreibt das Vorgehen zum Zusammenführen von Codeänderungen und Behandeln von Konflikten.

Ein Konflikthinweis bedeutet nicht automatisch, dass das ganze Projekt verloren ist. Er zeigt, dass Git die voneinander abweichenden Änderungen nicht sicher selbst kombinieren kann. Lesen Sie die markierten Stellen, entscheiden Sie anhand der Kursanforderung, welche Änderungen erhalten bleiben sollen, und prüfen Sie danach den zusammengeführten Code. Bei Unsicherheit sollte die Lehrkraft oder eine betreuende Person gefragt werden, bevor eine Fassung verworfen wird.

GitHub Desktop ersetzt keine Dateisicherung

GitHub Desktop überträgt nur Änderungen, die im Repository erfasst und anschließend gepusht wurden. Eine nicht gespeicherte Datei oder ein nicht ausgewählter Projektordner wird nicht automatisch aufgenommen. Für wichtige Kursabgaben sollte daher geprüft werden, ob die erwarteten Dateien im Repository auftauchen und ob der Remote-Stand nach dem Push abrufbar ist. Das gilt auch dann, wenn die Anwendung keine Fehlermeldung anzeigt.

Projektdateien und erzeugte Dateien unterscheiden

Nicht jede Datei, die während der Arbeit entsteht, gehört in eine Abgabe. Quellcode und benötigte Projektkonfiguration müssen entsprechend den Kursvorgaben verfügbar sein; lokale Dateien, temporäre Ausgaben oder wiederherstellbare Erzeugnisse können dagegen unnötig sein. Die konkrete Entscheidung hängt davon ab, welche Dateien das Projekt benötigt und was die Lehrkraft verlangt.

GitHub erklärt, wie Dateien über eine Ignore-Datei von der Versionsverwaltung ausgeschlossen werden. Als Ausgangspunkt kann die Swift-Vorlage für Ignore-Regeln dienen. Eine Vorlage ist jedoch keine verbindliche Projektregel: Entfernen Sie keine Datei allein deshalb aus dem Repository, weil sie in einer allgemeinen Vorlage aufgeführt ist. Prüfen Sie, ob das Projekt oder der Kurs sie benötigt.

Zugangspasswörter, Zugriffstoken und private Schlüssel gehören nicht in Commits. Eine Ignore-Regel schützt außerdem nicht rückwirkend, wenn eine vertrauliche Datei bereits eingecheckt wurde. Hinweise zum Umgang mit veröffentlichten Geheimnissen enthält die GitHub-Dokumentation zum Entfernen sensibler Daten aus einem Repository.

Übergabe vor dem Ortswechsel prüfen

• [ ] Das richtige Kurs-Repository und der vorgesehene Branch sind geöffnet.
• [ ] Der Speicherort der lokalen Arbeitskopie ist eindeutig.
• [ ] Die Änderungsliste enthält nur Dateien, die zur Aufgabe gehören.
• [ ] Commit-Nachricht und Commit beschreiben den beabsichtigten Zwischenstand.
• [ ] Der Push ist abgeschlossen, bevor auf den anderen Rechner gewechselt wird.
• [ ] Auf dem Remote-Mac wurde derselbe Branch aktualisiert.
• [ ] Xcode öffnet das erwartete Projekt und zeigt die benötigten Kursdateien.
• [ ] Nach der Mac-Arbeit sind die Änderungen geprüft, committet und gepusht.
• [ ] Unter Windows wurden Remote-Änderungen abgerufen, bevor weiterprogrammiert wird.
• [ ] Im Repository liegen keine Passwörter, Token oder privaten Schlüssel.

Wenn eine Zeile nicht abgehakt werden kann, stoppen Sie die Übergabe an dieser Stelle. So lässt sich unterscheiden, ob ein Problem beim lokalen Speichern, beim Commit, beim Push oder beim Öffnen des Projekts auftritt, statt später mehrere mögliche Ursachen gleichzeitig suchen zu müssen.

Für einen Einstieg in SwiftUI können Windows und GitHub Desktop für das Schreiben und geordnete Verwalten des Codes ausreichen. Sobald der Kurs Xcode verlangt, ersetzt dieser Ablauf jedoch keinen Mac: Windows kann den Stand vorbereiten und übergeben, aber nicht die Xcode-Arbeit auf dem Remote-Mac ausführen. Auch ein manuelles Kopieren des Projektordners ist als dauerhafte Übergabemethode schwächer, weil dabei leicht der falsche Stand, fehlende Dateien oder Änderungen ohne nachvollziehbare Historie weitergereicht werden.

Ein eigener Mac ist sinnvoll, wenn die Entwicklungsumgebung regelmäßig und langfristig benötigt wird oder physischer Zugriff auf Anschlüsse wichtig ist. Für eine einzelne Kursphase kann die Anschaffung dagegen unnötig sein; ein Remote-Mac bringt wiederum eine Netzwerkabhängigkeit mit sich und eignet sich nicht für jede Arbeitssituation. Wer zuerst die Anforderungen und den Ablauf einordnen möchte, findet einen Überblick zu NUKCLOUD und dem verfügbaren Angebot. Die Nutzungsbedingungen von NUKCLOUD sollten vor einer Buchung ebenfalls geprüft werden.

Wenn die aktuelle Windows-Lösung für den Kurs reicht, ist kein Wechsel nötig. Wird dagegen regelmäßig Xcode gebraucht, sind lokale Dateikopien wegen fehlender Versionsübersicht und die Arbeit nur unter Windows wegen der fehlenden Xcode-Umgebung keine gute Dauerlösung. Für eine zeitlich begrenzte Lern- oder Abgabephase kann ein gemieteter Remote-Mac von NUKCLOUD den benötigten Mac-Arbeitsplatz bereitstellen, ohne dass dafür sofort ein eigener Rechner angeschafft werden muss. Prüfen Sie vorher, ob Kurssoftware und Arbeitsweise zum Fernzugriff passen; Details zum Angebot stehen auf der NUKCLOUD-Seite.