Forum: PC-Programmierung Effizienter Umgang mit "fremden Code"


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Heinz K. (Gast)


Angehängte Dateien:

Lesenswert?

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?

von Dussel (Gast)


Lesenswert?

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.

von A. S. (rava)


Angehängte Dateien:

Lesenswert?

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.
von Heinz K. (Gast)


Lesenswert?

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 :)

von MaWin (Gast)


Lesenswert?

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

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

von dampfgelaber (Gast)


Lesenswert?

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.

von Jan K. (jan_k)


Lesenswert?

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.

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Lesenswert?

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
...

von Nico T. (wurstnase)


Lesenswert?

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.

von Experte (Gast)


Lesenswert?

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.
von MaWin (Gast)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.