Mein Tipp wre: Schau dir einige Git-Clients an und probiere einfach mal drauflos. Ich habe selbst sehr lange im Clinch mit Git gelegen (tue es zum Teil immer noch), aber so halbwegs geht es erst, seit ich Tower benutze, das vor allem eine schnell verfgbare Online-Hilfe bietet. Die Terminologie hatte mich ansonsten erschlagen.
Gro umstellen musst du bei Github selbst nichts, bis auf das .ignore-File, fr das ein Xojo-Preset existiert. Damit werden Builds und obsolete files, die im Projekt-Format angelegt werden, vom Upload ausgeschlossen.
Du kannst dir die Hoheit ber das Repository vorbehalten und deinen Azubi einen eigenen Branch forken lassen also einen Ableger der Daten zum derzeitigen Zeitpunkt. Wenn er sein Fenster bearbeitet hat, ldt er diesen hoch wobei nur seine nderungen bercksichtigt werden, bzw. auch separat sogar codezeilenweise ausgewhlt werden kann, was dazugehren soll. nderungen an deinem Fenster z.B. nicht Xojo verwurschtelt bei Abstrzen ja gerne mal einige Inspector Properties, was diese Objekte dann auch als gendert markiert.
Trifft der Merge Request bei dir ein, also die Bitte, Code hinzuzufgen, kannst du dir vorher anschauen, welche nderungen enstehen. Unerlaubte Bereiche kannst du rauspicken, und den Rest mit deinem Code mergen. Sollte es dabei Konflikte geben, werden dir diese angezeigt und du kannst whlen, wie alles zusammengefgt werden soll.
Machst du zwischenzeitlich ein Update, das einige Grundfunktionen ndert, kann dein Azubi wiederum diese nderungen in seinen Branch pullen wobei seine neue Daten dann eben nicht berschrieben werden.
Das ist alles gewhnungsbedrftig (und findet seine Limitationen bei Shared Code, weil der blicherweise im Binrformat abgelegt wird das wird auch verarbeitet, aber du siehst die nderungen nicht detailliert) und ist recht komplex, weil funktionsmchtig. Mit dem fr einen passenden Client macht es aber sogar Spa, grtenteils zumindest.
Zu deiner Nachfrage, @Marcel: Doch, klappt gut. Intern sind es beim Xojo-Projektformat ja auch nur Text-Dateien, das ist grundstzlich nichts anderes als viele andere Programmiersprachen auch schreiben. Funktionieren tut es, weil immer ein lokales Repository fr die eigenen Arbeiten existiert und beim Pullen und Pushen die nderungen mit dem Remote Repository verglichen werden.
Wie gesagt, ich bin auch kein Experte, aber wenn du Starthilfe bentigst, gib gerne Bescheid.
Hier mal ein Screenshot:
Ich habe Vernderungen an 48 Dateien vorgenommen. Unten habe ich das erste Objekt angeklickt das trgt ein blaues “M” fr “Modified”, und du siehst in Rot und Grn alten und neuen Code rechts. Letzteren kann ich ignorieren (Discard) oder bernehmen (Stage). Ich kann auch alles auf einmal bernehmen (Stage all) und es denn via Push auf das entfernte Repository schieben. Sollte man mal einen Fehler gemacht haben, kann man den Zustand wieder auf den eines bestimmten Zeitpunkts zurcksetzen.
Sind Bestandteile neu, haben sie ein grnes Icon, und entfallen welche, werden sie rot markiert. Wenn man relativ hufig in sein eigenes lokales Repository schreibt, bleibt die Liste auch sehr bersichtlich, nicht so wie hier 
