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?
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.
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
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 :)
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.
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.
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:
1
git checkout mein-branch
2
Änderungen...
3
git commit ...
4
git remote update origin
5
git merge origin/master
6
Konflikte beheben
7
git commit
8
Änderungen...
9
git commit ...
10
...
Umstellen:
1
git remote update origin
2
git checkout -b mein-rebase-branch origin/master
3
git checkout mein-branch . # der . ist wichtig
4
git reset # danach kann man alle Änderungen neu committen
5
git diff # zeigt jetzt alle Unterschiede zwischen origin/master und mein-branch
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.
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.
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.
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
Problem.png
(28 KB)
