Git: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
Frank (Diskussion | Beiträge) Git Pro Book URL |
|||
| (20 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
[[GIT|Git]] ist ein [[Versionsverwaltung|Versionsverwaltungssystem]]. Es wird verwendet um | {{TOCRight}}[[GIT|Git]] ist ein [[Versionsverwaltung|Versionsverwaltungssystem]]. Es wird verwendet um | ||
* Änderungen am Projekt zu protokollieren und diese zu archivieren. | * Änderungen am Projekt zu protokollieren und diese zu archivieren. | ||
* Ältere Versionen wiederherzustellen. | * Ältere Versionen wiederherzustellen. | ||
* Gemeinsames Arbeiten auf der selben Datenbasis zu ermöglichen. | * Gemeinsames Arbeiten auf der selben Datenbasis zu ermöglichen. | ||
Wir verwenden Git im | Wir verwenden Git im Softwarepraktikum um genau diese Punkte zu ermöglichen. Jede Gruppe erhält ihr eigenes [[#Repository|Repository]] auf [[Gitea]] (einer Plattform ähnlich zu [https://de.wikipedia.org/wiki/GitHub GitHub]), um ihr Projekt zu verwalten. | ||
__TOC__ | __TOC__ | ||
| Zeile 55: | Zeile 55: | ||
=== Remote === | === Remote === | ||
Remote ist die Bezeichnung für ein Repository, das zur Synchronisierung verwendet wird. Meistens ist dies auf einem externen Server und benötigt eine Authentifizierungsmethode um von diesem Änderungen zu holen (fetch) oder Änderungen hochzuladen (push). Im | Remote ist die Bezeichnung für ein Repository, das zur Synchronisierung verwendet wird. Meistens ist dies auf einem externen Server und benötigt eine Authentifizierungsmethode um von diesem Änderungen zu holen (fetch) oder Änderungen hochzuladen (push). Im Softwarepraktikum verwendet jede Gruppe dazu ein eigenes von uns mit [[Gitea]] gehostetes Repository. | ||
=== HEAD === | === HEAD === | ||
| Zeile 81: | Zeile 81: | ||
git config --global user.name "Jane Doe" | git config --global user.name "Jane Doe" | ||
Seiten wie GitHub oder auch | '''Hinweis''': Seiten wie GitHub oder auch unsere [[Gitea]] Instanz verwenden die Emailadresse um den Commit einem Benutzer zuzuordnen, die eingestellten Emailadressen sollten also übereinstimmen. | ||
== Repository erstellen == | == Repository erstellen == | ||
| Zeile 93: | Zeile 93: | ||
== Repository klonen == | == Repository klonen == | ||
Um ein bestehendes Repository in einen Ordner zu klonen benutzt man den clone Befehl | [[Datei:gitea_repoUrl.png|right|thumb|500px|In der Repositoryansicht von Gitea sieht man die genauen URLs für das eigene Gruppenrepository in der roten Box.]] | ||
Um ein bestehendes Repository in einen Ordner zu klonen benutzt man den <code>clone</code> Befehl. Dabei kann entweder HTTPS oder SSH als Protokoll verwendet werden. Beachten Sie dazu auch die Anleitungen zum [[Gitea#SSH Key hinzufügen|Hinzufügen eines SSH Keys zu Gitea]] und [[Gitea#HTTPS Kennwort einrichten|Setzen eines HTTPS Kennworts für Gitea]]. | |||
Für HTTPS verwendet man folgenden Aufruf: | |||
git clone https://git.sopranium.de/<semester>/<gruppe>.git | |||
Für SSH ist der äquivalente Befehl | |||
git clone gitea@ | git clone gitea@git.sopranium.de:<gruppe>/<gruppe>.git | ||
Der Befehl <code>clone</code> legt eine exakte Kopie der gesamten Repositorydaten auf der lokalen Maschine ab. | Der Befehl <code>clone</code> legt eine exakte Kopie der gesamten Repositorydaten auf der lokalen Maschine ab. | ||
| Zeile 105: | Zeile 108: | ||
== Am Repository arbeiten == | == Am Repository arbeiten == | ||
Im Folgenden zeigen wir die grundlegenden Handgriffe, die zur Benutzung von Git notwendig sind. Um tiefer in die Materie einzutauchen empfehlen wir [https://git-scm.com/book/de/v2 | Im Folgenden zeigen wir die grundlegenden Handgriffe, die zur Benutzung von Git notwendig sind. Um tiefer in die Materie einzutauchen empfehlen wir [https://git-scm.com/book/de/v2 Git Pro Book]. | ||
==== Neue Datei ==== | ==== Neue Datei ==== | ||
| Zeile 189: | Zeile 192: | ||
<tr><th><tt>bin</tt></th><td>Die Dateien in diesem Ordner werden automatisch beim [[Compiler|Kompillieren]] erstellt, sie hochzuladen ist also unnötig. Zudem sind auch binäre Dateien dabei die sich beim kompilieren häufig ändern. Da binäre Dateien nicht gemerged werden können wird das zu häufigen Konflikten mit den Commits anderer Teammitglieder führen.</td></tr> | <tr><th><tt>bin</tt></th><td>Die Dateien in diesem Ordner werden automatisch beim [[Compiler|Kompillieren]] erstellt, sie hochzuladen ist also unnötig. Zudem sind auch binäre Dateien dabei die sich beim kompilieren häufig ändern. Da binäre Dateien nicht gemerged werden können wird das zu häufigen Konflikten mit den Commits anderer Teammitglieder führen.</td></tr> | ||
<tr><th><tt>obj</tt></th><td>Siehe <tt>bin</tt>.</td></tr> | <tr><th><tt>obj</tt></th><td>Siehe <tt>bin</tt>.</td></tr> | ||
<tr><th><tt>*.suo</tt></th><td>Die Dateien mit der Endung .suo (''Solution User Options'') beinhalten eine Reihe von Benutzer-spezifischen Einstellungen für [[VisualStudioTutorial|Visual Studio]], die niemanden außer den Benutzer selber interessieren. Sie enthalten außerdem eine Reihe von absoluten Pfadangaben, die bei anderen Benutzern massive Probleme auslösen können. Sie sollen auf keinen Fall zum [[#Repository|Repository]] [[#Working Copy commiten|hinzugefügt]] werden.</td></tr> | <tr><th><tt>*.suo</tt></th><td>Die Dateien mit der Endung .suo (''Solution User Options'') beinhalten eine Reihe von Benutzer-spezifischen Einstellungen für [[VisualStudioTutorial|Visual Studio]], die niemanden außer den Benutzer selber interessieren. Sie enthalten außerdem eine Reihe von absoluten Pfadangaben, die bei anderen Benutzern massive Probleme auslösen können. Sie sollen auf keinen Fall zum [[#Repository|Repository]] [[#Working Copy commiten|hinzugefügt]] werden.</td></tr> | ||
<tr><th><tt>*.cachefile</tt></th><td>Siehe <tt>bin</tt>. Auch merkt sich [[MonoGame]] hier, welche Dateien es schon in ein ihm genehmes Format konvertiert hat. Wenn ein anderes Teammitglied eine neue Datei hinzufügt und diese Datei im <tt>.cachefile</tt> als bereits konvertiert markiert ist, kann es passieren daß sich XNA denkt "Hey die Datei hab ich doch schon" und sie nicht neu konvertiert.</td></tr> | <tr><th><tt>*.cachefile</tt></th><td>Siehe <tt>bin</tt>. Auch merkt sich [[MonoGame]] hier, welche Dateien es schon in ein ihm genehmes Format konvertiert hat. Wenn ein anderes Teammitglied eine neue Datei hinzufügt und diese Datei im <tt>.cachefile</tt> als bereits konvertiert markiert ist, kann es passieren daß sich XNA denkt "Hey die Datei hab ich doch schon" und sie nicht neu konvertiert.</td></tr> | ||
<tr><th><tt>*.thumb</tt></th><td>Von Windows generierte Datei, die Vorschaubilder für die Miniaturansicht im Explorer enthält.</td></tr> | <tr><th><tt>*.thumb</tt></th><td>Von Windows generierte Datei, die Vorschaubilder für die Miniaturansicht im Explorer enthält.</td></tr> | ||
<tr><th><tt>thumbs.db</tt></th><td>Siehe .thumb</td></tr> | <tr><th><tt>thumbs.db</tt></th><td>Siehe .thumb</td></tr> | ||
| Zeile 199: | Zeile 200: | ||
=== Mit mehreren Branches arbeiten === | === Mit mehreren Branches arbeiten === | ||
Im | Im Softwarepraktikum verwenden wir hauptsächlich 2 Branches (siehe [[GitWorkflow| Git Workflow im Softwarepraktikum]]). | ||
* ''' | * '''release''' => Hier ist der aktuelle Stand des Projekts in lauffähigem Zustand mit fertig implementierten Tasks. Dieser Branch ist Grundlage für die Bewertung des Spiels und Abgabe von Artefakten. Dieser Branch muss zu jeder Zeit ein kompillier- und lauffähiges Spiel darstellen. | ||
* ''' | * '''master''' => Hier werden die Tasks entwickelt. Sie müssen nicht zwangsläufig fertig sein, aber der master Branch soll zu jeder Zeit kompillieren und laufen. | ||
* feature/<task> => Feature branches ''können'' als Erweiterung des | * feature/<task> => Feature branches ''können'' als Erweiterung des master Branches gesehen werden. Hier wird ein einzelner Task implementiert bis er fertig ist und in den master Branch gemerged wird. | ||
==== Wichtige branch Befehle ==== | ==== Wichtige branch Befehle ==== | ||
| Zeile 213: | Zeile 214: | ||
==== Branch mergen ==== | ==== Branch mergen ==== | ||
Möchte man einen feature Branch nach | Möchte man einen feature Branch nach master mergen, wechselt man zunächst in den master Branch | ||
git checkout | git checkout master | ||
Jetzt merged man den feature Branch mit | Jetzt merged man den feature Branch mit | ||
| Zeile 223: | Zeile 224: | ||
Je nach Zustand des Repository gibt es nun mehrere Szenarios was passiert: | Je nach Zustand des Repository gibt es nun mehrere Szenarios was passiert: | ||
* '''Fast-forward Merge''' Falls man den aktuellen [[#HEAD|HEAD]] des | * '''Fast-forward Merge''' Falls man den aktuellen [[#HEAD|HEAD]] des master Branch durch einfaches zurücklaufen in der History des feature/<task> Branch erreichen kann, sind offensichtlich Konflikte ausgeschlossen und Git kann einfach den HEAD von master auf den HEAD des feature/<task> Branches zeigen lassen. Effektiv wird also alles was in feature/<brach> seit dem erstellen des feature/<brach> passiert ist auch in master passieren. | ||
* '''Recursive Merge''' Falls in der Zwischenzeit der | * '''Recursive Merge''' Falls in der Zwischenzeit der master Branch weiterentwickelt wurde, ist ein Fast-forward Merge nicht mehr möglich. Falls es aber keine Dateien gibt, die jetzt unterschiedliche Inhalte haben, wird bei einem recursive Merge ein neuer Commit erstellt, der die Vereinigung der Änderungen beider Branches darstellt. Git fordert den Nutzer in diesem Fall auf eine Commit Nachricht anzugeben. In der Regel sollte diese dann lauten: "''Merge feature/<task> Evtl zusätzliche Info oder Zusammenfassung für neues Feature.''" | ||
* '''Merge Konflikt''' Falls in beiden Branches Änderungen an gleichen Inhalten gemacht wurden, weiß Git nicht wie diese aufzulösen sind. Wie man Merge Konflikte löst ist in [[#Konflikte lösen|Konflikte lösen]] beschrieben. | * '''Merge Konflikt''' Falls in beiden Branches Änderungen an gleichen Inhalten gemacht wurden, weiß Git nicht wie diese aufzulösen sind. Wie man Merge Konflikte löst ist in [[#Konflikte lösen|Konflikte lösen]] beschrieben. | ||
* Weitere Möglichkeiten zu mergen werden hier beschrieben: https://git-scm.com/docs/merge-strategies | * Weitere Möglichkeiten zu mergen werden hier beschrieben: https://git-scm.com/docs/merge-strategies | ||
| Zeile 235: | Zeile 236: | ||
Die betroffenen Dateien kann man sich mit <code>git status</code> anzeigen lassen. Eine Ausgabe kann dann so aussehen: | Die betroffenen Dateien kann man sich mit <code>git status</code> anzeigen lassen. Eine Ausgabe kann dann so aussehen: | ||
On branch | On branch master | ||
You have unmerged paths. | You have unmerged paths. | ||
(fix conflicts and run "git commit") | (fix conflicts and run "git commit") | ||
| Zeile 253: | Zeile 254: | ||
1. Turn PC on. | 1. Turn PC on. | ||
Hier makiert alles zwischen <code><<<<<<< HEAD</code> und <code>=======</code> (In diesem Fall also <code># Setup</code>) den vom Konflikt betroffenen Bereich im aktuellen | Hier makiert alles zwischen <code><<<<<<< HEAD</code> und <code>=======</code> (In diesem Fall also <code># Setup</code>) den vom Konflikt betroffenen Bereich im aktuellen master Zustand. Ab <code>=======</code> bis <code>>>>>>>> feature/foo</code> (In diesem Fall also <code># Installation</code>) Den vom Konflikt betroffenen Bereich im feature/foo Branch. Alle diese Bereiche (es kann mehrere geben) müssen nun manuell aufgelöst werden. Dabei ist es wichtig auch die Git Markierungen zu entfernen. Eine Lösung könnte also sein: | ||
# Setup | # Setup | ||
| Zeile 266: | Zeile 267: | ||
Hat man die Konflikte in dem Tool behoben, fügt Git die Dateien automatisch zur Stage hinzu, so dass man nur noch den merge Commit machen muss. | Hat man die Konflikte in dem Tool behoben, fügt Git die Dateien automatisch zur Stage hinzu, so dass man nur noch den merge Commit machen muss. | ||
= Git | = Git im Softwarepraktikum = | ||
== Git für das Softwarepraktikum vorbereiten == | |||
== Git für das | |||
Nachdem Sie sich für einen Git-Client entschieden haben, müssen Sie sicherstellen: | Nachdem Sie sich für einen Git-Client entschieden haben, müssen Sie sicherstellen: | ||
* Dass ihr [[Gitea|Zugang zu Gitea]] funktioniert. | * Dass ihr [[Gitea|Zugang zu Gitea]] funktioniert. | ||
* Das Repository Ihrer Gruppe auf ihren [[#Repository | * Das Repository Ihrer Gruppe auf ihren [[#Repository klonen|Rechner klonen]]. | ||
* Ihren [[#Name und Email einstellen|Namen und die Email]] Adresse Git mitteilen. | * Ihren [[#Name und Email einstellen|Namen und die Email]] Adresse Git mitteilen. | ||
* Stellen Sie sicher, dass eine <code>.gitignore</code> Datei mit den Regeln in der unter [[#Dateien Ignorieren|Dateien Ignorieren]] gegebenen Tabelle in ihrem Gruppenrepository im master Branch existiert. | * Stellen Sie sicher, dass eine <code>.gitignore</code> Datei mit den Regeln in der unter [[#Dateien Ignorieren|Dateien Ignorieren]] gegebenen Tabelle in ihrem Gruppenrepository im master Branch existiert. | ||
== Git und Gitea == | == Git und Gitea == | ||
Gitea kann nicht nur die Commitmessages aus dem Repository anzeigen. In der Commitmessage kann auf ein Ticket verwiesen werden, indem man einfach die Nummer des Tickets (links neben dem | Gitea kann nicht nur die Commitmessages aus dem Repository anzeigen. In der Commitmessage kann auf ein Ticket verwiesen werden, indem man einfach die Nummer des Tickets (links neben dem Tickettitel in Gitea) mit ''#'' davor, angibt. Das sorgt auch dafür, dass der Commit in den Kommentaren des Tickets aufgelistet wird. Tickets können per Commitmessage geschlossen werden, indem davor noch ''closes'' (oder ''close, fix, fixes'') geschrieben wird. | ||
=== Beispiele === | === Beispiele === | ||
| Zeile 289: | Zeile 286: | ||
<source> | <source> | ||
Dieser Commit schließt das Ticket mit | Dieser Commit schließt das Ticket mit Nummer 33, closes #33. | ||
</source> | </source> | ||
| Zeile 296: | Zeile 293: | ||
</source> [[Kategorie:Code-Beispiele]] | </source> [[Kategorie:Code-Beispiele]] | ||
Anmerkung: eine Referenz auf einen Issue darf nicht am Anfang einer Zeile stehen (dort leitet <code>#</code> eine | Anmerkung: eine Referenz auf einen Issue darf nicht am Anfang einer Zeile stehen (dort leitet <code>#</code> eine Überschrift ein) | ||
<source> | <source> | ||
#Dies ist eine Überschrift! | #Dies ist eine Überschrift! | ||
| Zeile 307: | Zeile 304: | ||
* [http://rogerdudler.github.io/git-guide/ Einfacher Git Guide] | * [http://rogerdudler.github.io/git-guide/ Einfacher Git Guide] | ||
* [https://git-scm.com/ Offizielle Webseite] | * [https://git-scm.com/ Offizielle Webseite] | ||
* [https:// | * [https://github.github.com/training-kit/downloads/github-git-cheat-sheet.pdf Git Cheat-Sheet] | ||
* [https://git-scm.com/docs Offizielle Dokumentation] | * [https://git-scm.com/docs Offizielle Dokumentation] | ||
=== Referenzen === | === Referenzen === | ||
