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.