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
Beitrag #6660151 wurde von einem Moderator gelöscht.
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 :)
Heinz K. schrieb: > nach dem nächsten "git pull" git rebase ist eigentlich das geeignetere Tool für diesen Fall.
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 |
6 | git add -p # Änderungen thematisch gruppieren |
7 | git commit -m "erster patch" |
8 | git add -p |
9 | git commit -m "zweiter patch" |
10 | ... bis alles wieder drin ist |
11 | neue Änderungen... |
12 | git commit ... |
13 | ... |
14 | git remote update origin |
15 | git rebase -i origin/master |
16 | evtl. Konflikte beheben |
17 | git add -u |
18 | git rebase --continue # bis alles wieder drin ist |
Weiterarbeiten:
1 | Änderungen... |
2 | git commit ... |
3 | ... |
4 | git remote update origin |
5 | git rebase -i origin/master |
6 | evtl. Konflikte beheben |
7 | git add -u |
8 | git rebase --continue # bis alles wieder drin ist |
9 | Änderungen... |
10 | git commit ... |
11 | ... |
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.
Beitrag #6660537 wurde von einem Moderator gelöscht.
Beitrag #6660864 wurde von einem Moderator gelöscht.
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
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.