Einzelnen Beitrag anzeigen

Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#4

AW: Suche Versionierungsstrategie für ... Projektumbau

  Alt 28. Jan 2017, 13:44
Ich bin mir nicht sicher, ob ich das Problem ganz verstanden habe. Geht es eigentlich um zwei getrennte Repositories oder um ein einziges Repository?

Also ich kann dir sagen, was ich mit Git mache, was möglicherweise so ähnlich ist. Ich bin aber auch kein Experte was Versionierungsstrategien angeht und lerne gerne dazu.

Mein Problem ist, dass ich den Linux-Kernel mit ein paar Patches betreibe, die irgendwann mal für Version 3.16 oder so geschrieben wurden (aktueller Kernel ist 4.10). Diese Patches applyen natürlich längst nicht mehr, weil sich vieles geändert hat. Ich will es so haben, dass diese Patches immer auf das neueste Release applyen. Dazu benutze ich git rebase.

Der Workflow ist wie folgt.

Angenommen, ich habe Version 4.7 bereits gepatcht. Die gepatchte Version ist getaggt mit "v4.7-patched". Als erstes wechsel ich zu diesem Tag.
Code:
git checkout "v4.7-patched"
Das Commit-Log sieht so aus:
Code:
git log --format=oneline

9976c0407c25d69c0f7c0c0c1c6aa99a875fede3 [PATCH] Patch 2 <-- obendrauf meine Patches
fb28d356d6f8b098a2aaed6638085bcffaab2329 [PATCH] Patch 1 <-- obendrauf meine Patches
523d939ef98fd712632d93a5a2b588e477a7565e Linux 4.7 <-- letzter regulärer Commit des Upstream-Linux
68093c43f352e4ad36cf1324bbdbd7c723a24dbc Merge tag 'ceph-for-4.7-rc8' of git://github.com/ceph/ceph-client
107df03203bb66de56e2caec3bde6d22b55480c5 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
88083e9845612826dfd44a5215647b4f6567317c Merge branch 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs
b1386cedda177b10fac009ca8d3681034f15b5b3 Merge branch 'akpm' (patches from Andrew)
...
Ich möchte jetzt diese Patches (Changesets) auf Version 4.8 portieren.
Code:
git rebase "v4.8"
(Jetzt dauert es ein bisschen und ich muss eventuell ein paar Konflikte auflösen.)

Anschließend sieht es hoffentlich so aus:
Code:
git log --format=oneline

9325f55909f3582a49f04d41ce574c82cb49674b [PATCH] Patch 2
d7334192f868c44a7717a21bcb494026138179bf [PATCH] Patch 1
c8d2bc9bc39ebea8437fd974fdbc21847bb897a3 Linux 4.8
f76d9c61d91343806e59335493806e87daf78947 Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm
117e5e9c4cfcb7628f08de074fbfefec1bb678b7 ARM: 8618/1: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
be67d60ba944bdd38571b79bdcd506e34c0f16c1 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
66188fb11a82692629e85b6cbc3ecc08c752d2dc Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus
...
Man beachte dass dort jetzt "Linux 4.8" steht statt "Linux 4.7". Und wieder sind "meine" Patches oben drauf, so als wären sie als letztes committed worden – das ist das wichtige.

Nun bin ich schon fast am Ziel. Jetzt muss ich den Zustand nur noch archivieren:
Code:
git tag "v4.8-patched"
Fertig.

Durch den Tag ist dieser Zustand nun eindeutig und für immer identifizierbar. Und ich kann jederzeit mit git checkout zu früheren Tags zurück. (Ich kann z.B. danach wieder zu "v4.7-patched" zurück und sehe dann wieder das erste Log. Die Patches "verschwinden" also nicht von dort oder so.)

Hoffe es war nicht am Thema vorbei.
  Mit Zitat antworten Zitat