Git: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
Roth (Diskussion | Beiträge) Adapt branch names to Sopra usage. develop -> master. master -> release. |
|||
| Zeile 200: | Zeile 200: | ||
=== Mit mehreren Branches arbeiten === | === Mit mehreren Branches arbeiten === | ||
Im SOPRA verwenden wir hauptsächlich 2 Branches (siehe [[GitWorkflow| Git Workflow im Sopra]]). | Im SOPRA verwenden wir hauptsächlich 2 Branches (siehe [[GitWorkflow| Git Workflow im Sopra]]). | ||
* ''' | * '''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 und 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 213: | ||
==== 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 223: | ||
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 235: | ||
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 253: | ||
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 | ||
