"Vagy ez vagy pedig a fájloknak csak egy részét/részletét commitolod és reménykedsz, hogy önmagában is fordul a felcommitált rész, mert te külön nem fordítottad. Gányolás mindkettő. Nem hiszem, hogy lenne jó megoldás, függetlenül attól, hogy git vagy svn."
Git-et használva kétféleképpen lehet kezelni az ilyen eseteket:
- Miután az indexhez hozzáadtad a következő commitba szánt változtatásokat, lehetőséged van arra, hogy elrejtsd a working treeből az összes olyan változtatást, ami nem lesz része a következő commitnak (git stash --keep-index), így lefordíthatod és tesztelheted azt az állapotot, ami majd a következő commit lesz.
- Amíg egy commit csak a lokális repository-dban létezik, addig nincs kőbe vésve, és egyszerűen módosítható. Tehát a refaktorizálás + új funkció példádban megteheted, hogy teszteletlenül commitolod a refaktorizálást, majd miután az új funkciót is commitoltad, akkor utólag leellenőrzöd a refaktorizáló commitot, és ha gáz van, akkor kijavítod. Amikor már kész vagy, és mindkettő fordul és átmegy a teszteken, akkor push-olod a nyilvános/központi repository-ba.
"Tehát svn-ben a refactoringot vagy az új funkcióval együtt teszi fel az ember, ami nem túl szép, viszont garantáltan fordul, vagy ha más fájlokban van a refactoring, akkor sikerülhet külön is. Szerintem nem vészesen nagy a különbség, feltéve, ha az ember értelmes logot ír hozzá."
Például ha később egy bug levadászása során a bisect pont ezt a commitot hozza ki bűnösnek, akkor kérdéses, hogy a refaktorizálás okozta-e a hibát vagy az új funkció nem kívánt mellékhatása. Ez nyilván hátrány, bár arról lehetne vitatkozni, hogy "vészesen nagy" e. Én nem fogok, de örülök, hogy olyan eszközt használhatok, amivel mindez már nem probléma.