[mioDuus]

Dzisiaj o tym jak zmigrować się z wielu repozytoriów do mono-repo bez tracenia historii Git'a.

https://pandablog.pl/migracja-do-mono-repo-bez-tracenia-historii-gita

#programowanie #webdev #git #javascript #java #php #frontend #backend #pandablog #python

[JarJobs_com]

@mioDuus: hej, ciekawy wpis, chętnie dodamy go do jutrzejszej #prasowkait

[dennijs]

@mioDuus: szukam tego programu z miniaturki

[sidhellfire]

@dennijs: chyba vscode + plugin git log history

[Aryo]

@sidhellfire: @dennijs: Wtyczka git graph do VS Code

[sidhellfire]

@Aryo: To dodam, że Git Lens też fajne

[misieg8]

@mioDuus: pytanko apropos monorepo. zalozmy ze uzywamy semvera i mamy w monorepo komponenty A i B, ktore sa splitowane do swoich osobnych read-only repozytoriow. czyli jak zmienie cos tylko w A i ta zmiana bedzie wymagala podniesienia wersji major to rozumiem, ze automatycznie w B tez zmienia sie major mimo ze w samym kodzie tego komponentu nic sie nie zmienilo? czy ja to dobrze rozumiem? bo wtedy traktuje cale monorepo jako

[dennijs]

@Aryo: danke

[mioDuus]

ktore sa splitowane do swoich osobnych read-only repozytoriow

@misieg8: nie rozumiem, chodzi Ci jakieś repo typu meta? Generalnie mono-repo to mono-repo, masz jedno repo i jedną wersję, dla wszystkich zależnych komponentów

[zakopiak]

nie rozumiem,

@mioDuus: Jeśli robisz soft, który składa się z jakichś tam wielu niezależnych komponentów, to z jednej strony chcesz łatwo rozwijać projekt, a więc masz monorepo, ale z drugiej dystrybuować komponenty niezależnie, żeby można ich było używać pojedynczo. Dlatego tworzy się wtedy repozytoria read-only dla poszczególnych komponentów, gdzie kopiowany jest ich kod. Typowe dla frameworków. Symfony tak miało, ale z czego widzę, teraz mają już realne repozytoria dla każdego komponentu,