Git, GitHub & Rstudio [DE]

Modulüberblick

In diesem Modul geht es um das Versionskontrollsystem git, den Cloud-Dienst GitHub und deren Verwendung in RStudio.

git ist ein Versionskontrollsystem, das die Erstellung von Snapshots von Dateien oder ganzen Verzeichnisbäumen ermöglicht. Auch das Kombinieren und Vergleichen solcher Snapshots ist komfortabel möglich.

GitHub ist die bekannteste Cloud-basierte Arbeitsumgebung auf Basis von Git und bietet darüber hinaus eine Vielzahl webbasierter Werkzeuge und Dienste.

RStudio ist als so genannte integrierte Entwicklungsumgebung (IDE) eine Desktop-Anwendung, die nicht nur für R/Python generische Programmieruntersützung bietet, sondern auch das wissenschaftliche Schreiben und Dokumentation, von Daten und Texten sehr gut unterstützt- Durch die vollständige Integration von Pandoc und Tex bietet es darüber hinaus eine weitgehende und sehr komfortable Unterstützung bei der Erstellung von Dokumenten in Form von Texten in allen denkbaren Formaten, interaktiven Dokumenten und Websites.

Lernziele

Am Ende des Moduls werdet ihr in der Lage sein, git, GitHub und Rstudio effizient zu verwenden. Ein besonderer Schwerpunkt liegt dabei auf der praktischen Anwendung. Konkret beschäftigen wir uns mit:

  • Was ist eine Versionskontrolle?
  • Was unterscheidet git und GitHub?
  • Die zentralen Vorgänge, Pull, Status, Add, Commit, Push
  • Vermeidung und Auflösung von Versionskonflikten
  • Nutzung mit RStudio

Git und GitHub leicht gemacht

Lernziele

In dem Teilmodul Git und GitHub leicht gemacht lernst du:

  • das Konzept der Versionskontrolle
  • die Einsatzgebiete von GitHub und Git

Voraussetzungen

Überblick

Was ist eine Versionskontrolle und wofür ist sie gut? Versionskontrollsysteme sind Softwaretools, die Personen bei der Verwaltung von Änderungen an Texten, Quellcode, wissenschaftlichen Analysen oder Dokumentationen unterstützen.

Im Falle eines Fehlers können die Autor:innen die Änderungen einsehen und mit früheren (Teil-)Versionen vergleichen, um Korrekturen vorzunehmen und gleichzeitig die Unterbrechung ihrer eigenen Arbeit oder der Arbeit von Teammitgliedern zu minimieren.

Du hast zum Beispiel einen Ordner, in dem du ein Projekt hast, das aus verschiedenen Dateien besteht (Text, Programmcode, Bilder, Sounddateien usw.), und du möchtest die Änderungen verfolgen, die du an diesen Dateien vorgenommen hast.

Die Software git protokolliert alle Änderungen an diesen Dateien. Wie geht das?

1. git mitteilen, dass eine Datei oder ein Verzeichnis aufgezeichnet werden soll.

2. git mitteilen, dass der Zustand der Datei zu einem bestimmten Zeitpunkt aufgezeichnet werden soll.

Dieser Prozess ist also in zwei Schritte unterteilt, die kontrolliert und ausgelöst werden müssen. Um definierte Änderungen vornehmen zu können, muss festgelegt werden, was überwacht werden soll und es muss explizit bestätigt werden, dass ein definierter Zustand gespeichert wird. Im Prinzip muss also, wie bekannt, eine Momentaufnahme der Datei oder des Projektes bestätigt gespeichert werden.

Der große Unterschied ist jedoch, dass nur die Änderungen dieses Sicherungsvorganges aufgezeichnet werden und später auch in diesen Teilschritten wiederhergestellt werden können.

Git - Erste Schritte

Bei der Verwendung von Git muss zunächst ein Repository in einem Verzeichnis auf dem lokalen Rechner aktiviert werden. Dies geschieht mit dem Befehl git init. Nun weiß Git wo, aber nicht was es verfolgen soll.

graph LR
    A(Erzeuge einen <br> neuen Ordner) -.-> B[Lokaler Ordner <br> 'MeinOrdner']
    B -- git init --> C[Lokales Repository <br> 'Mein Ordner']
    C -.- D(git überwacht <br> 'MeinOrdner' <br> 'kennt' aber keine Inhalte)
  

    classDef gr fill:#9f6,stroke:#333,stroke-width:2px
    classDef bl fill:#6BC9F5,stroke:#333,stroke-width:2px,stroke-dasharray: 1
    classDef or fill:orange,stroke:#333,stroke-width:1px,stroke-dasharray: 3
    classDef or2 fill:orange,stroke:#333,stroke-width:3px,stroke-dasharray: 2
    class A bl
    class D gr
    class C,B or

%%{init: {'theme':'forest'}}%%

Initialisierung eines Repositories

Die Veränderungen an Dateien des Projekts werden jedoch nur dann übwerwacht wenn git ausdrücklich darüber “informiert” wird. Dies geschieht mit dem Befehl git add. Soll eine überwachte Datei gesichert werden erfolgt das mit dem Befehl git commit. Der Befehl, git push wird dann verwendet wenn die bestätigten Verzeichnis-Snapshot in ein entferntes Repository (z.B. Github, GitLab) übertragen werden sollen.

graph LR
    AA[Projektordner <br> 'MeinOrdner'] --git init--> 
    BB[Ordner ist als  <br> Repository vorbereitet] --git add DateiNeu-->
    CC(Die DateiNeu <br> wird 'überwacht') -.git commit.-> 
    DD(Die Datei DateiNeu ist <br> in aktueller Version <br> lokal gespeichert) --git push--> 
    EE(Die DateiNeu  ist <br> auf dem GitHub<br> Repo gespeichert)
    
    A[Projektordner <br> 'MeinOrdner'] -.-> 
    B[Lokales Repository <br> 'MeinOrdner'] -- Erzeugen einer Datei -->
    C[Überwachte Datei <br> in 'MeinOrdner'] -.-> 
    D[Dateiversion im <br> lokalen Repository ] -.-> 
    E[Dateiversion im <br> entfernten Repository ]
    

    classDef green fill:#9f6,stroke:#333,stroke-width:2px
    classDef blue fill:#6BC9F5,stroke:#333,stroke-width:2px,stroke-dasharray: 2
    classDef orange fill:orange,stroke:#333,stroke-width:1px,stroke-dasharray: 3
    class A blue
    class B,C,D,D,E,F green
    class DD,CC,AA,BB,EE orange

Ablauf init-add-commit-push

Mit dem Befehl ist git status erhälst du einen Überblick über den Status aller Dateien innerhalb eines initialisierten Repository Ordners. Du solltest in der Lage sein, die Ausgabe dieses Befehls zu interpretieren:

git status - konzeptionelle Inhalte

Git/GitHub: pull, status, add, commit, push

Es gibt zwei typische Szenarien für die Benutzung von Git und GitHub.

  1. du hast das Projekt noch nicht gestartet und möchtest ein GitHub-Repository, das du als Vorlage auf deinen Rechner kopieren (klonen) und dann lokal mit Dateien und Verzeichnissen nach deinen Wünschen füllen kannst.
  2. Du hast das Projekt bereits lokal gestartet und möchtest es auf GitHub kopieren.

Beide Szenarien werden von Jenny Bryan exzellent erläutert. Bitte lies diese Texte und folge den Anweisungen.

Gut zu wissen

Wenn du mehr über Git erfahren möchtest, findest du hier weitere hilfreiche Ressourcen:

Selbst-Check

Fork und Branches auf GitHub

Lernziele

In dieser Lektion lernst du

  • Was ein Fork/Branch eines GitHub-Repositorys ist.
  • Wie man einen Branch eines GitHub Repositories erstellt.
  • Wie Du ein GitHub Repository von einem Branch aus aktualisierst.

Vorausetzungen

  • Vertrautheit mit GitHub-Repositorys.
  • Git muss auf deinem Computer installiert sein.
  • Ein GitHub Konto!

Was ist ein Fork/Branch?

Wenn man in Gruppen an GitHub-Projekten arbeitet, wird es lästig, wenn eine Person den gesamten Code alleine in das Repository einpflegen muss. Hier kommen Forks und Branches ins Spiel. - Mit Branches kannst Du eine Kopie des aktuellen GitHub-Projekts nehmen und auf Deinem eigenen Computer Änderungen vornehmen. Sobald Du und Deine Gruppe Änderungen am Code vorgenommen habt, könnt Ihr die Änderungen wieder in Eure ursprüngliche Projektgruppe einfügen. - Branches können auch verwendet werden, wenn Du an einem Teil eines Projekts getrennt von den anderen Teilen arbeiten möchtest. - Forks sind sehr ähnlich, mit dem Unterschied, dass sie Kopien bzw Klone eines kompletten Projekts an einem anderen Ort sind.

Wie erstelle ich einen Branch?

Um einen Branch von einem GitHub Repository zu erstellen, gehe zu dem Hauptrepository, an dem du arbeiten möchtest und klicke auf das Dropdown-Menü, das “main” heißen sollte. Es sollte wie das folgende Bild aussehen.

Branch Menu in GitHub

Sobald man auf dieses Menü klickt, erscheint auf GitHub ein Textfeld mit der Aufschrift “Find or create a branch…”, man gibt einen neuen Namen für den Zweig ein, z.B. ‘newbranch1’. Da dieser Zweig noch nicht existiert, fragt dich GitHub, ob du einen Zweig mit dem Namen “newbranch1” erstellen möchtest. Klicke auf “Create branch: newbranch1” und der neue Zweig wird für Dich erstellt, wie in der folgenden Abbildung zu sehen ist.

Erzeugung eines neuen Branches

Wie stellt man einen Pull Request?

Eine Pull-Anfrage ermöglicht es dem Eigentümer des GitHub-Projekts, Deine Änderungen zu überprüfen, um sicherzustellen, dass sie in das aktuelle Repository passen und keine Konflikte in Deinem Repository verursachen.

Um eine Pull-Anfrage von Deinem Zweig aus zu stellen, musst Du zuerst eine Änderung an Deinem Zweig-Repository vornehmen. Sobald Du eine Änderung an Deinem Zweig vorgenommen hast, erscheint ein gelber Balken auf Deinem Bildschirm, der Dich fragt, ob Du eine Pull-Anfrage stellen möchtest. Wie Du auf dem Bild unten sehen kannst, gibt es einen grünen Button, und sobald Du darauf klickst, kannst Du eine Pull-Anfrage erstellen.

Initialisierung eines Pull Requests

Sobald Du auf den Button klickst, informiert Dich GitHub, ob es Probleme beim Zusammenführen des Zweigs mit dem Hauptprojekt gibt. Wenn es keine Probleme gibt, setzt GitHub ein Häkchen und zeigt “Able to merge” an. Du kannst dann einen Titel und einen Kommentar zu Deiner Pull-Anfrage hinzufügen, um den Besitzer des Repositorys darüber zu informieren, was Du getan hast. Sobald Du einen Kommentar und einen Titel eingegeben hast, kannst Du auf “Create a pull request” klicken. Wenn Du dies getan hast, wird eine Benachrichtigung an den Besitzer des Repositorys gesendet, dass Deine Änderungen zur Überprüfung bereit sind.

Nachdem Du Deine Anfrage abgeschickt hast, kann der Besitzer des GitHub-Projekts auf die Seite des Projekts gehen und auf den Reiter “Pull Requests” klicken. Auf dieser Seite wird eine Liste von Pull Requests angezeigt, aus der der Eigentümer Deine Anfrage auswählen kann. Sobald der Besitzer auf der Pull Request Seite angekommen ist, sieht er eine Schaltfläche mit der Aufschrift “Merge pull request” (ähnlich der Abbildung unten).

Bearbeitung eines Pull Requests

Sobald der Eigentümer auf die grüne Schaltfläche klickt, wird er erneut gefragt, ob er die Änderung vornehmen möchte. Wenn er erneut auf den Button klickt, wird die Änderung mit dem Hauptzweig zusammengeführt und er sieht etwas wie das folgende Bild…

Mergen eines verifizierten Pull Request

Ein Repository in einem Branch (oder Fork) aktualisieren

Wenn jemand in deiner Gruppe eine Änderung am Master Repo vornimmt, gibt es eine Möglichkeit, deinen Zweig zu aktualisieren, damit du die Änderungen sehen kannst. Wenn eine Änderung vorgenommen wurde, wird auf der Webseite des verzweigten Repos angezeigt, dass Dein Repo “1 Commit behind the Master” ist. Das bedeutet, dass es 1 Änderung zwischen Deinem Fork und dem Main Repository gibt.

Wenn Du Deinen Fork aktualisieren möchtest, klicke auf die Schaltfläche “Änderungen”. Du wirst dann auf eine Seite geleitet, die sagt “main is up to date with all commits from branch. Versuchen Sie die Basis zu ändern”. Klicke auf “Change base”. Dann wird angezeigt, ob der Zweig zusammengeführt werden kann. Wenn ja, klicke auf “Create pull request” (Titel und Kommentar für deine Anfrage) und erstelle eine Pull-Anfrage.

Nun klicke auf Merge pull request, dann auf Confirm merge und dein Zweig wird aktualisiert!

Gut zu wissen

Selbst-Check

Umgang mit Konflikten

Lernziele

In dieser Lektion lernst du

  • Wie man mit Konflikten umgeht, die bei der Arbeit mit GitHub auftreten.
  • Wie man mit Merge-Konflikten in GitHub umgeht.

Vorausetzungen

  • Vertrautheit mit GitHub.
  • Git installiert haben.
  • Ein GitHub Konto haben.

Versionskonflikt - was ist das?

Versionskonflikte entstehen normalerweise, wenn verschiedene Versionen derselben Datei gleichzeitig in das Hauptrepository gepusht werden und die Priorisierung der Dateien nicht klar ist, also:

  • wenn man sein persönliches GitHub-Repository aktualisiert (kein Pull vor Push).
  • wenn mehrere Personen gleichzeitig an derselben Datei arbeiten

Push & Pull Konflikte

Ein typisches Szenario ist, dass Du etwas online auf GitHub bearbeitest und diese Änderung nicht gleichzeitig oder später in Rstudio synchronisierst. Der Konflikt könnte z.B. sein, dass Du einen Tippfehler in der README korrigierst und vergisst, die aktuelle Version im Rstudio-Projekt zu aktualisieren.

Ein komplizierterer Fall ist, wenn eine Änderung im Master-Repository gemacht wurde und jemand anderes in seinem Branch-/Fork-Repository ebenfalls eine Änderung an der gleichen Datei bzw. dem gleichen Inhalt gemacht hat. Wenn eine Pull-Anfrage gestellt wird, wird GitHub den Unterschied bemerken. Auch hier kann es sich um etwas so Einfaches handeln, wie zwei Personen, die die README auf unterschiedliche Weise aktualisieren, was GitHub dazu veranlasst, ein Problem zu melden.

In diesem Fall muss manuell entschieden werden, welche Variante Vorrang hat.

Wenn Du eine Änderung an Deinem GitHub-Repository vornimmst und es gibt einen Konflikt, zeigt Dir R an, dass Deine Version dem Haupt-Repository voraus ist, wenn Du Deine Änderung überträgst. Wenn Du dies siehst, bedeutet es, dass es einen Unterschied zwischen den Dateien gibt. Wenn Du versuchst zu pullen und es gibt ein Problem, wird GitHub Dir etwas sagen wie

Updates wurden abgelehnt, weil das entfernte Repository Arbeit enthält, die Du lokal nicht hast. Dies wird normalerweise durch ein anderes Repository verursacht, das auf die gleiche Referenz pusht.

Wenn diese Meldung erscheint, empfiehlt GitHub, dass Du einen Pull von Deinem Master-Repository durchführst, um den Fehler zu finden. Häufig erhältst Du die Fehlermeldung

CONFLICT (content): Konflikt beim Zusammenführen in [Datei]. Automatisches Zusammenführen fehlgeschlagen; Konflikte lösen und dann das Ergebnis übertragen.

Die Datei mit dem Problem wird dann in Ihrem RStudio geöffnet und zeigt den gefundenen Fehler an. Es wird angezeigt, welche Änderungen vorgenommen wurden und welche Unterschiede zum Hauptzweig bestehen (die Änderungen werden unter <<<<<<< HEAD angezeigt, der Inhalt des Hauptzweigs wird darunter angezeigt). Du musst den Fehler zwischen den beiden Versionen beheben, indem Du entweder das beibehältst, was GitHub bereits hat, oder indem Du Deine Änderung so anpasst, dass sie dem entspricht, was Du machen wolltest. Wenn Du mit Deiner Änderung zufrieden bist, rufe das Terminal auf (es befindet sich in R, einem Tab über der Konsole). Im Terminal gibst Du git add [Dateiname] ein, drückst die Eingabetaste und gehst zurück zum Git-Tab oben rechts im RStudio-Fenster. Wähle die Datei aus, in der der Fehler aufgetreten ist und überschreibe sie, um den Fehler zu beheben.

Merge Konflikte

Wenn mehrere Personen am selben GitHub-Repository arbeiten oder Du nur einen Zweig verwendest, besteht die Möglichkeit, dass ein Merge-Konflikt auftritt. Zusammenführungskonflikte treten auf, wenn Änderungen am Haupt-Repository und an einem Zweig vorgenommen werden, die nicht übereinstimmen. Sobald eine Pull-Anfrage gestellt wird, muss der Eigentümer des Projektarchivs die Änderungen manuell überprüfen, sie können dann nicht automatisch zusammengeführt werden.

Folglich teilt GitHub Dir mit, dass es die Versionen nicht automatisch zusammenführen kann, aber es wird Dir trotzdem erlauben, die Pull-Anfrage zu stellen. Wenn Du Dich entscheidest, die Pull-Anfrage zu senden, wird der Repo-Besitzer nicht in der Lage sein, auf den grünen Merge Button zu klicken, sondern er wird eine Meldung sehen, die besagt:

Dieser Zweig hat Konflikte, die gelöst werden müssen.

Rechts neben dieser Meldung befindet sich die Schaltfläche Konflikte auflösen.

Wenn du auf die Schaltfläche Konflikte auflösen klickst, wirst du zu einer Seite weitergeleitet, die ähnlich aussieht wie bei Push- oder Pull-Fehlernt. Du siehst die vorgeschlagenen Änderungen aus dem Zweig und Haupt-Repository. An dieser Stelle können dann Änderungen durchgeführt werden und zuletzt mit Als gelöst markieren und anschließend Merge bestätigen erfolgreich für einen Merge bereitgestellt werden. Zuletzt muss der Eigentümer auf Merge Pull Request und dann auf Commit Merge klicken, um die Änderung im Haupt-Repository zu vorzunehmen.

Gut zu wissen

  • Immer pull vor push, sonst hat GitHub zwei verschiedene Änderungen gespeichert und weiß nicht, welche zu verwenden ist.

  • Weitere Informationen über den Umgang mit Konflikten in GitHub findest Du in den GitHub Docs.

Selbst-Check

RStudio - All Inclusive

Lernziele

  • Einsatz von GitHub direkt aus RStudio

Vorausetzungen

  • Übung im Umgang mit GitHub und git

Existierendes GitHub Repo in R einbinden

Bevor du mit einem GitHub-Repository in RStudio arbeitest, stelle sicher, dass du ein GitHub-Repository hast, mit dem du arbeiten kannst.

Nachdem du das Repository erstellt hast, kannst du auf die grüne Schaltfläche klicken, um einen Link zu erhalten, mit dem du das Repository klonen kannst. Um es in R zu öffnen, öffne R und klicke auf den Würfel mit dem Pluszeichen, um ein neues Projekt zu erstellen, klicke auf Versionskontrolle und dann auf Git. Nun fügt man die zuvor kopierte URL ein und erstellt das Projekt. Jetzt hast du ein Projekt in R, das mit GitHub verbunden ist. Nun kannst du neue Dateien erstellen und sie auf GitHub hochladen, damit andere sie sehen können.

Erklärung der Schaltflächen/Befehle

Oben rechts (je nach Konfiguration von RStudio) befinden sich die Reiter Environment, History... Wähle die Registerkarte Git, um die Git-Befehle zu sehen. In diesem Bereich kannst Du entscheiden, welche Dateien hochgeladen/gelöscht, welche Änderungen übernommen, welche Dateien aus dem Haupt-Repository gezogen, welche Dateien in das Haupt-Repository geschoben werden sollen. Die vorgenommenen Änderungen werden hier überprüft und es können Branches erstellt oder geändert wrden. Sehen wir uns nun an, was die einzelnen Befehle/Schaltflächen bewirken.

  • Diff Wenn du auf Diff klickst, öffnet sich ein neues Fenster in R. In diesem Fenster werden alle Dateien angezeigt, die sich geändert haben (im Vergleich zum Haupt-Repository) und auch die Änderungen, die du vorgenommen hast. Du kannst dieses Fenster auch verwenden, um die Änderungen zu übertragen und aus dem Haupt-Repository herauszuziehen.

  • Commit Die Verwendung von Commit im kleineren Fenster ist ähnlich wie im Diff-Fenster, Du musst nur die Dateien auswählen, die Du ins Repository übertragen möchtest und dann die Änderungen committen.

  • Pull Pull ist ziemlich selbsterklärend, es zieht Dateien aus dem GitHub Repository. Es ist wichtig, Dateien vor dem Pushen zu ziehen, um mögliche Konflikte mit überlappenden Dateien zu vermeiden.

  • Push Push schiebt die Dateien in das GitHub Repository. Diese Funktion wird verwendet, wenn Du die Änderungen an Deinen Dateien abgeschlossen hast und bereit bist, sie hochzuladen, damit andere die neuen Dateien ansehen können. Die Reihenfolge beim Hochladen dieser Dateien wäre: Änderungen übertragen, aus dem Repository ziehen und dann in das Repository pushen.

  • History Das nächste Symbol ist eine kleine Uhr, die die Historie Deiner Arbeit darstellt. Sie zeigt die bisherigen Übertragungen und was bei jeder Übertragung geändert wurde.

  • Revert, Ignore und Shell Diese Befehle findest Du in einem Dropdown-Menü, nachdem Du auf das Zahnrad neben der Uhr geklickt hast. Mit Revert kannst Du alle Änderungen rückgängig machen, mit Ignore kannst Du einen Gitignore einrichten (nützlich, um Dateien zu blockieren, die Du nicht hochladen willst) und mit Shell kannst Du Dein Terminal öffnen und dort Git-Befehle ausführen.

  • Branches Das nächste Symbol steht für Zweige. Wenn Du auf dieses Symbol klickst, wirst Du gefragt, ob Du einen neuen Zweig erstellen möchtest. Wie Du im Modul Zweige des Toolkits gelernt hast, sind Zweige nützlich, um Änderungen zu testen, ohne dass sie sich auf den Hauptzweig auswirken, falls ein Fehler auftritt. Du kannst das Dropdown-Menü rechts neben dem Zweigsymbol verwenden, um zwischen den Zweigen zu wechseln.

  • Terminal (optional) Du kannst diese GitHub-Befehle mit den RStudio-Befehlen ausführen, aber du kannst auch das Terminal in R verwenden, um das gleiche zu tun. Alle GitHub-Befehle sind in der Form “git _____” und Du kannst sie finden, indem Du “git” in Dein Terminal eingibst. Dies macht dasselbe wie das R-Panel, aber wenn Du mit dem Schreiben von Git-Befehlen in einem Terminal vertrauter bist, funktioniert es vielleicht besser für Dich.

Ein R-Projekt in ein GitHub-Repositorium verwandeln

Manchmal arbeitet man an einem Projekt in R und hat vergessen, ein GitHub-Repository dafür zu erstellen. In diesem Fall kann Ihnen das Paket usethis helfen, ein Repo aus RStudio heraus zu erstellen. Mit der Funktion usethis::use_git kann das aktuelle Projekt in ein GitHub Repo umgewandelt werden, so dass die Dateien hochgeladen werden können. - Wenn Du diese Funktion zum ersten Mal ausführst, wirst Du wahrscheinlich einen Fehler erhalten, da Du dafür ein Token von GitHub benötigst. Nach dem Aufruf von usethis::browse_github_token öffnet sich ein neues Fenster, in dem man aufgefordert wird, sich in seinen GitHub-Account einzuloggen. Nach dem Einloggen können Berechtigungen mit dem Token gesetzt und kopiert werden. Sobald du den Token kopiert hast, rufe usethis::edit_r_environment() auf und speichere deinen Token als “GITHUB_PAT=token”.

Sobald dein Token gesetzt und dein R zurückgesetzt ist, kannst du use_git benutzen und es wird Dich fragen, ob es okay ist, deine Dateien zu GitHub zu committen. Wenn du diese Frage bejahst, wirst du aufgefordert, dein RStudio-Fenster neu zu starten, um das Git-Fenster zu öffnen und deine Dateien hochzuladen. Nach dem Neustart von RStudio die geänderten Dateien (falls vorhanden) mit dem Diff-Button hochladen. Benutze nun usethis::use_github, um deine Dateien in ein GitHub-Repository zu senden. - use_github wird Dich fragen, ob Du einen ssh Schlüssel hast, was Du wahrscheinlich nicht hast, also wähle https. Dann wird man gefragt, ob Titel und Beschreibung akzeptabel sind. Wenn ja, kannst Du mit Ja antworten und die Datei auf GitHub hochladen!

Typische Probleme

  • Du versuchst, git commit auszuführen, nachdem du Änderungen an einer Datei vorgenommen hast, aber du trackst diese Datei(en) nicht. Deshalb müssen Sie zuerst git add ausführen.

  • Du versuchst git push auszuführen, um Deine Aktualisierungen in das entfernte Repository zu übertragen, aber dieses existiert nicht.

  • Du versuchst git push auszuführen, um deine Aktualisierungen in das entfernte Repository zu übertragen, obwohl es bereits neue Aktualisierungen im entfernten Repository gibt (z.B. von einem anderen Teammitglied), die du noch nicht in das lokale Projekt übertragen hast. Die Fehlermeldung, die du bekommst, wird in etwa so aussehen:

Fehler: Deine lokalen Änderungen an den folgenden Dateien würden beim Zusammenführen überschrieben: … Bitte übertrage oder speichere deine Änderungen vor dem Zusammenführen.

Du weist also dein lokales git an, deine eigenen Änderungen hinzuzufügen, ohne die Änderungen deines Teamkollegen zu berücksichtigen - ein klassischer Loyalitätskonflikt. Der beste Weg, dieses Problem zu vermeiden, ist immer einen git pull durchzuführen, bevor man mit dem lokalen Editieren beginnt.

Gut zu wissen

Weitere Informationen zur Verwendung von GitHub in RStudio findest Du unter folgendem Link:

  • Der Blog-Eintrag GitHub & Rstudio zeigt, wie man Git in RStudio benutzt und geht dabei besonders auf die Terminal-Befehle ein.

Selbst-Check

Danksagung

Das Tutorial basiert auf dem DoSStoolkit. insbesondere unter Nutzung des Moduls Git outta here von Mariam Walaa & Matthew Wankiewicz. Die Übersetzungen und Veränderungen sowie eininge der Graiken sind vom Autor dieser Seite.

Das Originalmodul kann mit dem folgenden R-Befehl aufgerufen werden.

learnr::run_tutorial("git_outta_here", package = "DoSStoolkit")