Inzicht in bezwaren bij het gebruik van Git
Er zijn drie veelvoorkomende bezwaren die ik vaak hoor om te migreren naar Git:
- Ik kan de geschiedenis overschrijven.
- Ik heb grote bestanden.
- Er is een steile leercurve.
Geschiedenis overschrijven
Git biedt technisch gezien de mogelijkheid om geschiedenis te overschrijven, maar net als elke nuttige functie, als misbruik conflicten kan veroorzaken.
Als uw teams voorzichtig zijn, moeten ze de geschiedenis nooit overschrijven.
Als u synchroniseert met Azure-opslagplaatsen, kunt u ook een beveiligingsregel toevoegen die voorkomt dat ontwikkelaars de geschiedenis overschrijven met behulp van de expliciete pushmachtigingen forceren.
Elk broncodebeheersysteem werkt het beste wanneer ontwikkelaars begrijpen hoe het werkt en welke conventies werken.
Hoewel u de geschiedenis niet kunt overschrijven met Team Foundation Version Control (TFVC), kunt u nog steeds code overschrijven en andere pijnlijke dingen doen.
Grote bestanden
Git werkt het beste met opslagplaatsen die klein zijn en geen grote bestanden (of binaire bestanden) bevatten.
Telkens wanneer u (of uw buildcomputers) de opslagplaats kloont, krijgen ze de hele opslagplaats met de geschiedenis van de eerste doorvoering.
Het is geweldig voor de meeste situaties, maar kan frustrerend zijn als u grote bestanden hebt.
Binaire bestanden zijn nog erger omdat Git niet kan optimaliseren hoe ze worden opgeslagen.
Daarom is Git LFS gemaakt.
Hiermee kunt u grote bestanden van uw opslagplaatsen scheiden en nog steeds alle voordelen hebben van versiebeheer en vergelijking.
Als u ook gecompileerde binaire bestanden opslaat in uw bronopslagplaats, stopt u!
Gebruik Azure Artifacts of een ander hulpprogramma voor pakketbeheer om binaire bestanden op te slaan waarvoor u broncode hebt.
Teams met grote bestanden (zoals 3D-modellen of andere assets) kunnen Echter Git LFS gebruiken om de codeopslagplaats slank en ingekort te houden.
Leercurve
Er is een leercurve. Als u nog nooit broncodebeheer hebt gebruikt, bent u waarschijnlijk beter af bij het leren van Git. Ik heb ontdekt dat gebruikers van gecentraliseerd broncodebeheer (TFVC of SubVersion) in eerste instantie de mentale verschuiving maken, vooral rond vertakkingen en synchroniseren.
Zodra ontwikkelaars begrijpen hoe Git-vertakkingen werken en het feit dat ze moeten doorvoeren en vervolgens pushen, hebben ze alle basisbeginselen die ze nodig hebben om te slagen in Git.