Bunteshaus/spielwiese
3
1
Fork 2
Code Issues Pull Requests Releases Activity

konzept_commit_history.md: ergaenzungen zum Umgang mit Branches #5

Merged
teldra merged 1 commits from teldra/spielwiese:aenderungen into main 2021-06-12 22:24:58 +02:00
Conversation 0 Commits 1 Files Changed 1 +18 -2
1 changed files with 18 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
konzept_commit_history.md
View File

@ -41,7 +41,7 @@ eintragen soll.
Wir haben nun folgenden zustand: Wir haben den Branch "main" der einen Commit hinter "vorwort"
zurueckliegt in der History der Commits.
Mit dem Branch "vorwort" koennten wir nun folgendes tun: Wenn wir an einem Projekt mit mehreren
Mit dem Branch "vorwort" koennten wir nun vieles tun: Wenn wir an einem Projekt mit mehreren
Personen teilnehmen haben wir das Projekt ja vorher geforkt und in unserem Account. Also pushen
wir diesen Branch zu dem Repository wo er dann auch als Branch vorliegt und machen dann einen
Pull-Request auf das urspruengliche Repository von dem geforkten Repository.
@ -49,4 +49,20 @@ Pull-Request auf das urspruengliche Repository von dem geforkten Repository.
Oder wir machen auf unseren eigenen "main" Branch einen Pull-Request. Oder wir mergen den
einfach in unseren eigenen "main" Branch und machen dann einen Pull-Request auf den "main"
des Originals. Ich weiss das hoert sich jetzt wirr an aber ab hier kommt es drauf an, was
mensch machen will.. und vorher machte..
mensch machen will.. und vorher machte..
Wir lernen im Prinzip: Ein Repsository ist eine Sammlung von Dateien wie ein Ordner.
In diesem Ordner gibt es mindestens eine History der Dateien mit dem Namen "main" oder "master".
Ich kann Branches anlegen, die die Geschichte des Branches enthaelt von dem wir abzweigen um
unabhaengig vom originalen Branch Aenderungen zu machen. Die Historys verschiedener Branches mit
gleichem Ursprung koennen zusammengefuehrt werden. Entweder direkt via merge, wenn es ein eigenes
Repository ist oder generell wenn Schreibrechte auf das Zielrepository vorhanden sind oder
via pull-request, wenn es ein fremdes Zielrepository ist bzw. wenn keine Schreibrechte vorhanden sind.
Wenn es keine Konflikte gibt, passiert dann alles automatisch.
Konflikte entstehen, wenn ich einen Zustand einer Datei habe, der vom Zustand der Datei die ich
veraender im Original abweicht. Zb. weil jemand anders in der Zwischenzeit die Datei an Stellen
geaendert hat, an denen ich Arbeitete. Das wird dann bemerkt und es werden moeglichkeiten zum loesen
des Konfliktes angeboten. Mit einem guten Workflow und einer Einstellung fuer git wird das Risiko
aber aus Gruenden reduziert.