( asch | 2025. 01. 08., sze – 00:31 )

Szerintem a két VSS két branch lehet a git-ben, és biztonsági mentés pedig egy külön kérdés, a központi git-et rendszeresen menteni kell és kész.

>A Gitben ugyan erre vannak a branch-ek, de nem vagyok abban biztos, hogy ennyire el szeretném bonyolítani a dolgokat...

Ez szerintem egyszerűbb mint két verziókezelőt tartani.

> Különbség nézés

Bármely két commit között (különböző ágak, vagy egymás utáni kommitok) között tudsz különbséget nézni a git difftool -d paranccsal. Ha be van konfolva, akkor egy GUI-s könyvtár összehasonlító programot indít. Én a meld-et használom (lásd: https://meldmerge.org/ ), az a kedvencem, de van több ilyen eszköz is.

Hasonlóan a merge-hez is be lehet állítani külső toolt, ami 3 way merge-öt kezel: látod a közös őst és a két állapotot a két ágon. Erre is meld-ez használok.

 

> ami a VSS-ből lekérdezi, mely állományok vannak nálam kikölcsönözve, ezeket feldobja nekem egy ablakban, ahol egyesével tudok megjegyzéseket írni hozzájuk, majd a végén az általam engedélyezett állományokat visszaírja (check-in) a VSS-be,

Ez nekem olybá tűnik, hogy a commitot szétszeded utólag fájlokra, hogy külön commentet kapjanak. Bár én ilyet nem csinálnék, de erre is van lehetőség, a commitokat tudod utólag szerkeszteni git-tel (de nem biztos, hogy egyszerű elsőre).

> Ez a lépés bárhányszor ismételhető, amíg úgy nem döntök, élesíthető az elkészült kód.

Egy feature branchen reszelgetheted a kommitjaidat ameddig csak tetszik, ez is megoldható git-tel.

>A tényleges élesítésre is van egy saját programom

Ez a lépés csak egy merge: az előkészített feature branch-et merge-ölöd az integrationbe (master, main, stb, sok neve lehet). Ezzel felülírod ott a fájlokat, ez a merge lényege. Utána a főágra tett trigger indít egy buildet, és az autobuild elkészíti az exe-ket, meg bemásolja ahová kell - ez már ugye build automatizálás kérdése.