Effizienter Umgang mit "fremden Code"

[Heinz K. (Gast)]

Hallo zusammen,

ich benötige Eure Hilfe: für meinen 3D-Drucker existiert eine frei 
verfügbare Firmware (Marlin), welche auf github gehostet wird.

Ich habe mir mittels "git clone" eine lokale Kopie erzeugt, die 
notwendigen Anpassungen für meinen Drucker vorgenommen, die Firmware 
compiliert und geflasht - soweit funktioniert alles gut.

Nun wird die Firmware dank vieler Freiwilliger kontinuierlich ständig 
weiterentwickelt, so dass es nicht ganz unwahrscheinlich ist, dass ich 
in Zukunft auch auf einen neueren Stand wechseln werde.

Meine Frage an Euch ist, wie ich meine lokale Kopie am Besten 
organisiere, so dass ich

a) meine persönlichen Änderungen am aktuellen Code möglichst 
automatisiert in den nächsten Stand (nach dem nächsten "git pull") 
übernehmen kann  und

b) ich den jetzigen Stand (welcher gut funktioniert) jederzeit wieder 
restaurieren kann.

Eine Möglichkeit wäre, dass ich meine lokale Kopie in ein lokales 
git-repository spiele; damit könnte ich bzgl. a) auf diff und merge 
zurückgreifen und bzgl. b) mit eigenen Tags bzw. Branches arbeiten, aber 
geht dies noch irgendwie einfacher?

[Dussel (Gast)]

Wenn du geklont hast, hast du doch schon ein lokales Repository. Ich 
würde meine Änderungen wohl in einen eigenen Branch tun. Dann kann man 
den Master pullen und bei Bedarf in den eigenen Branch mergen.
Das sollte man öfter tun, damit man nicht später tausende Zeilen merge 
hat.

[A. S. (rava)]

git hat viele Möglichkeiten. Ich würde auch so vorgehen:

mach dir einen lokalen Entwicklungsbranch und pflege da deine Änderungen 
ein.

Wenn du ein update ziehen und ausprobieren möchtest, kannst du den 
(master) branch aus dem Repo ziehen und damit spielen. Wenn dir das 
gefällt, kannst du deinen lokalen branch auf master "rebasen" und damit 
die Änderungen übernehmen.

Dafür würde ich möglicherweise einen weiteren branch machen, um zurück 
gehen zu könnten, falls etwas nicht klappt

[Heinz K. (Gast)]

Danke für die Hinweise!

Ich beschäftige mich viel zu wenig mit git und vergesse immer wieder, 
dass es sich um ein dezentrales VCS handelt und dass ich damit alle 
nötigen Werkzeuge lokal zur Verfügung habe :)

[MaWin (Gast)]

Heinz K. schrieb:
> nach dem nächsten "git pull"

git rebase ist eigentlich das geeignetere Tool für diesen Fall.

[dampfgelaber (Gast)]

was sind denn deine konkreten Änderungen? Vielleicht hat das Projekt ja 
ohnehin interesse an deinen Änderungen, und dann sind sie schwupps im 
master-branch drin und du musst dich um nichts mehr kümmern.

Ansonsten ist ein regelmäßiges mergen vom upstream-branch das 
einfachste. Ein rebase deiner Änderungen macht eigentlich nur Sinn, wenn 
du deine Änderungen zur veröffentlichung vorbereiten willst, oder sie 
als "patchset" weiter pflegst oder weitergeben willst.

Wenn es nur um ein bischen gebastel geht, dann ist das gelegentliche 
mergen das einfachste.

[Jan K. (jan_k)]

MaWin schrieb:
> Heinz K. schrieb:
>> nach dem nächsten "git pull"
>
> git rebase ist eigentlich das geeignetere Tool für diesen Fall.

Full ack. Wenn du regelmäßig die Änderungen von extern bei dir 
einfließen lassen willst, nimm 'git pull --rebase'. Oder fetch und dann 
rebase. Du musst natürlich Konflikte Lokal bei dir lösen, das musst du 
beim merge aber genauso.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Grob gesagt schmeisst ein git pull / git merge origin alle fremden 
Änderungen oben darauf so dass die eigenen immer tiefer in der 
Vergangenheit verschwinden. Und immer schwerer nachvollziehbar werden, 
vor allem wenn man merge-Koflikte lösen muß.
Bei git rebase schwimmen die eigenen Änderungen auf den fremden. 
Manchmal läuft man auf und mußt merge-Konflikte lösen, aber die bleiben 
im Stapel der eigenen Änderungen.
Die Arbeit von merge conflicts ist in etwa gleich - nur das Umwandeln 
von pull-Stil auf rebase-Stil wird immer schwieriger. Meist behilft man 
sich damit dass man erst mal alle Änderungen vom merge-Stil 
zusammenwirft und dann per git add -p in einzelne, übersichtliche 
Patches neu zusammenfasst die dann auf dem Upstream-HEAD schwimmen:

Merge-Stil:

git checkout mein-branch
Änderungen...
git commit ...
git remote update origin
git merge origin/master
Konflikte beheben
git commit
Änderungen...
git commit ...
...

Umstellen:

git remote update origin
git checkout -b mein-rebase-branch origin/master
git checkout mein-branch .   # der . ist wichtig
git reset  # danach kann man alle Änderungen neu committen
git diff   # zeigt jetzt alle Unterschiede zwischen origin/master und mein-branch
git add -p  # Änderungen thematisch gruppieren
git commit -m "erster patch"
git add -p
git commit -m "zweiter patch"
... bis alles wieder drin ist
neue Änderungen...
git commit ...
...
git remote update origin
git rebase -i origin/master
evtl. Konflikte beheben
git add -u
git rebase --continue # bis alles wieder drin ist

Weiterarbeiten:

Änderungen...
git commit ...
...
git remote update origin
git rebase -i origin/master
evtl. Konflikte beheben
git add -u
git rebase --continue # bis alles wieder drin ist
Änderungen...
git commit ...
...

[Nico T. (wurstnase)]

Welche Änderungen hast du denn gemacht? Nur welche in den 
Config-Dateien? Oder im sonstigen Code? Ist schon ein paar Jahre her, 
dass ich bei Marlin mitgeholfen habe und auch überhaupt genutzt habe, 
aber ich habe eigentlich nie das Bedürfnis gesehen, im Code ,neben der 
Config-Datei, was zu ändern.

[Experte (Gast)]

Egal ob man mit merge oder rebase arbeitet, wichtig ist bei solchen 
Sachen, dass man es kontinuierlich tut. Ansonsten sind die 
Upstream-Änderungen so groß, dass so ein merge oder rebase zur 
Mamut-Aufgabe wird, oder wegen veränderter Architektur verunmöglicht 
wird.

Das Kernproblem ist eben, man muss den Quark ständig pflegen. Über die 
Zeit akkumuliert sich der eigene Aufwand beträchtlich. Deshalb ist es 
absolut zielführend, sich um eine Integration der eigenen Änderung in 
den Upstream zu bemühen, sofern es die Chance dazu gibt. Auch wenn der 
Aufwand dafür am Anfang groß ist. Mittel- und Langfristig fährt man 
damit deutlich besser. Auch das rumschlagen mit möglicherweise komischen 
Upstream-Maintainer und deren lustigen Regeln lohnt sich.

[MaWin (Gast)]

Experte schrieb:
> Das Kernproblem ist eben, man muss den Quark ständig pflegen.

Es gibt natürlich auch noch die Möglichkeit es zu forken und nicht zu 
pflegen oder nur für einen begrenzten Zeitraum zu pflegen.
Kommt natürlich auf den konkreten Einsatzzweck an, ob man das machen 
kann.
Aber wenn jetzt so eine 3D-Drucker-Firmware funktioniert, dann könnte es 
auch eine Möglichkeit sein, einfach mit dieser Version für immer, bis 
das Gerät ersetzt wird, zu fahren.

[Oliver S. (oliverso)]

Heinz K. schrieb:
> Ich habe mir mittels "git clone" eine lokale Kopie erzeugt, die
> notwendigen Anpassungen für meinen Drucker vorgenommen, die Firmware
> compiliert und geflasht - soweit funktioniert alles gut.

Die entscheidende Frage ist, wie und wo diese Anpassungen verteilt sind.

Is das ein Art Treiber, der sich an wenigen wohldokumentierten Stellen 
in die Originalsoftware einhängt, kann das klappen. Nicht 
vollautomatisch, aber doch mit überschaubarem Aufwand.

Sind das dagegen hunderte Änderungen, über die ganze Software verteilt, 
lass es.

Experte schrieb:
> Egal ob man mit merge oder rebase arbeitet, wichtig ist bei solchen
> Sachen, dass man es kontinuierlich tut.

So ist es. Wenn du da nicht den Takt der Originalsoftware mitgehst, wird 
jedes erneute Zusammenführen eine Mammutaufgabe.

Oliver