Een groot binair bestand uit uw Git-geschiedenis verwijderen om de grootte van gekloonde opslagplaatsen te beheren

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Git is een populaire opslagplaats voor gedistribueerde broncode (opslagplaats) waarmee gebruikers met de volledige opslagplaats kunnen werken terwijl de verbinding is verbroken. De voordelen van Git zijn goed gedocumenteerd, maar wat gebeurt er als u de klok wilt terugdraaien op de primaire opslagplaats? Dit is niet intuïtief en vereist verhoogde machtigingen. Deze vereiste wordt verwacht voor iets dat van invloed is op elke gebruiker van de opslagplaats.

Hoe kunt u de centrale repository veilig terugzetten?

Probleemscenario

Stel dat u een groot bestand, zoals een video, doorvoert op uw Git-server. In een traditioneel broncodesysteem is het handig om alles op één plek op te slaan en vervolgens op te halen wat u nodig hebt. Met Git wordt de hele opslagplaats gekloond naar de lokale computer van elke gebruiker. Met een groot bestand moet elke gebruiker in het project ook de grote bestanden downloaden.

Met elk volgend groot bestand dat is doorgevoerd op de server, neemt het probleem alleen toe. De opslagplaats wordt te groot om efficiënt te zijn voor de gebruikers. Zelfs als u het grote bestand verwijdert uit uw lokale opslagplaats en het opnieuw doet, bestaat het bestand nog steeds in de geschiedenis van de opslagplaats. Als gevolg hiervan wordt het bestand nog steeds gedownload naar de lokale computer van iedereen als onderdeel van de geschiedenis.

Schermopname van het dialoogvenster 'Changes' in Team Explorer met grote video inbegrepen in de wijzigingen.

Voeg een groot bestand toe aan de lokale opslagplaats.

Schermopname van server- en lokale opslagplaatsen, beide met een kopie van de grote videobestanden.

Nadat u een commit heeft uitgevoerd vanuit de lokale repository, heeft de server ook het grote bestand.

De opslagplaats bevriezen

Als u het probleem van een grote opslagplaats wilt oplossen, moet u beginnen bij de bron. In dit scenario is de bron de serveropslagplaats. Vraag het team om te stoppen met het uploaden naar de repository. Als er tijdens dit proces meer pushes worden uitgevoerd, moet u er rekening mee houden zodat u geen gegevens kwijtraakt.

Belangrijk

Met de volgende stappen verwijdert u de video uit uw vertakkingsgeschiedenis, maar blijft het bestand in uw opslagplaatsgeschiedenis wanneer u uw opslagplaats kloont uit Azure-opslagplaatsen. Als u de bestanden uit de vertakkingsgeschiedenis verwijdert, voorkomt u dat de bestanden worden bijgewerkt, waardoor een andere versie van het grote bestand in uw opslagplaats is gemaakt.

Meer informatie over het beheren van grote bestanden in Git. Voor een uitleg en tijdelijke oplossing voor dit gedrag wanneer u Azure Repos Git-opslagplaatsen gebruikt, raadpleegt u Waarom retourneert klonen van Visual Studio Team Services oude niet-verwijzende objecten?.

Opnieuwbase en geforceerd pushen

Als niemand anders in het team wijzigingen heeft aangebracht in de repository, die meestal via een push plaatsvinden, kunt u de makkelijke weg kiezen. In wezen zorgt u ervoor dat uw lokale opslagplaats eruitziet zoals u wilt dat deze eruitziet (dat wil gezegd, zonder het grote bestand). Vervolgens dwingt u uw wijzigingen af op de server.

Mogelijk moet u uw lokale repository klonen of repareren voordat u aan dit werk begint. Dit proces kan leiden tot verloren werk of wijzigingen, dus wees voorzichtig.

Standaard kunt u lokale projectbestanden wijzigen en wijzigingen naar de server pushen, maar u kunt geen bewerkingen op serverniveau uitvoeren, zoals verwijderen of opnieuw maken. Als u wilt doorgaan, hebt u Force push-machtigingen (de voorkeur) of beheerdersmachtigingen voor de repository nodig. Neem contact op met de projectbeheerder om deze machtigingen aan te vragen of vraag iemand die ze al heeft om te helpen. Zie Machtigingen voor Git-opslagplaatsen instellen voor meer informatie.

Schermopname van de opdrachtprompt - git push --force-machtigingen.

Vervolgens moet u de opslagplaats opnieuw maken.

  1. Gebruik git log om de hashwaarden van de Secure Hash Algorithm (SHA) van de meest recente commits te vinden. U hebt deze informatie op een gegeven moment nodig, omdat u de meest recente goede commit moet weten. U kunt deze informatie ophalen door een Git-opdrachtprompt te openen en het volgende in te voeren:

    git log

    U kunt de SHA-hash ook ophalen door de vertakkingsgeschiedenis in Visual Studio Team Explorer te bekijken.

    Schermopname die de optie 'Geschiedenis bekijken' van de hoofdtak toont.

  2. Open een Git-opdrachtprompt.

    Schermopname van de actie Opdrachtprompt openen in het dialoogvenster Synchronisatie.

  3. Zoek het sha-hashnummer van belang.

    Schermopname van de opdrachtprompt voor de videodoorvoering.

    U hebt de SHA nodig die begint 25b4.

    Houd er rekening mee dat Git pointers gebruikt om te bepalen waar zich in de opslagplaats de hoofd- of huidige vertakking bevindt. De toestand van de repository waarin u geïnteresseerd bent bevindt zich op een bepaald moment in het verleden.

  4. Gebruik de git rebase opdracht om terug te gaan in de tijd en de vorige status de nieuwe huidige status te geven:

    git rebase -i <SHA hash of desired new current branch>

    Schermopname van het gebruik van rebase om het videobestand te verwijderen.

    De -i schakelaar biedt extra veiligheid omdat deze de geschiedenis in een editor weergeeft. (In dit artikel wordt een implementatie van Git gebruikt waarmee de klassieke vi-editor op de opdrachtregel in Windows wordt weergegeven. U weet het misschien nog als u met een Unix-systeem hebt gewerkt.)

  5. In dit voorbeeld voert u het volgende in:

    git rebase -i 25b4

  6. Nadat de editor is geopend, verwijdert u alle pick regels, met uitzondering van de vertakking die u wilt behouden als uw nieuwe hoofdvertakking. Wanneer alles er correct uitziet, voer in vi :w\<enter\> in om op te slaan of voer !q\<enter\> in om af te sluiten zonder op te slaan.

    Schermopname van de opdrachtprompt - git rebase -i 25b4 pick-opdracht.

    Wijzig de lijnen die u niet meer wilt.

    Schermopname van de opdrachtprompt - git rebase -i opdracht 25b4 drop.

  7. Verander pick naar drop zoals weergegeven. Voer :w vervolgens (in vi) in om op te slaan en voer in :q! om de rebase te starten.

    Voer nu opnieuw in git log . De problematische vertakking moet afwezig zijn in het log. Als dat het is, bent u klaar voor de laatste stap, waarvoor projectbeheerdersmachtigingen zijn vereist:

    git log

    Schermopname van lokale opslagplaatsen en server-opslagplaatsen na herbase.

    De commit voor de grote video is nu verwijderd uit de lokale repository.

  8. Voer de volgende opdracht in:

    git push --force

    Schermopname van de opdrachtprompt - git push --force.

    Schermopname van de opdrachtprompt - git push --force resultaat.

    Met dit commando wordt uw repository gedwongen om de repository op de server te overschrijven.

    Gebruik deze opdracht met voorzichtigheid omdat u eenvoudig gegevens op de server kunt verliezen.

    Schermopname van een geforceerde push met inhoud die moet worden bewaard, zonder het grote videobestand.

U moet zich verifiëren bij de server om deze actie te laten werken.

Als je Azure Repos gebruikt, moet je mogelijk een alternatieve referentie instellen zonder speciale tekens. Een voorbeeld is het at-symbool (@) in een e-mailadres. Volg de instructies in Authentication with Azure Repos om deze taak uit te voeren.

De tak is nu definitief van de server verwijderd. Volgende klonen en synchronisaties door projectteamleden downloaden niet de grote bestanden die u probeerde te verwijderen. Gebruikers moeten van de server naar beneden trekken om ervoor te zorgen dat ze gesynchroniseerd zijn met de status van de nieuwe serveropslagplaats.

Als gebruikers nieuwere commits hebben

Als andere gebruikers commits naar het serverrepository hebben gepusht, moet u een andere factor overwegen. U wilt de vertakking met de grote bestanden verwijderen, maar u wilt de wijzigingen die het team heeft aangebracht niet verliezen. Als u deze situatie wilt oplossen, moet u goed naar de commits kijken wanneer u de editor opent als onderdeel van het rebasing. Zorg ervoor dat de commits die u wilt behouden op de pick regels vermeld worden. Verwijder de bestanden die u wilt verwijderen, bijvoorbeeld waar een groot bestand is toegevoegd.

Na het rebasen moeten de andere gebruikers in het team ook rebasen, zodat iedereen een consistente kopie van de server-repo heeft. Dit werk is vervelend voor iedereen en je wilt het vermijden. Als u een push moet verwijderen, moet u dit afstemmen met het team. Voor meer informatie over rebasing, zie Git-branching - Rebasing.

De sleutel is om ervoor te zorgen dat u de commits kent die u wilt en de commits die u niet wilt. Onderzoek de git log of de historie in uw geïntegreerde ontwikkelomgeving (zoals Visual Studio). Noteer de SHA-hashes die u wilt behouden en de hashes die u wilt verwijderen.

In scenario's waarin het grote bestand oud is en er volgende vertakkingen en samenvoegingen waren, kunt u het bestand mogelijk verwijderen met behulp van de git filter-branch schakeloptie. Zie Gevoelige gegevens verwijderen uit een opslagplaats voor meer informatie.

Overwegingen voor beste praktijken

Zorg ervoor dat grote bestanden buiten de hoofdrepo blijven om teamleden extra werk te besparen. Hier volgen enkele algemene aanbevolen procedures voor het team om rekening mee te houden.

Wat u moet doen

  • Wijzigingen regelmatig doorvoeren. Je kunt ze later altijd herstellen door te squashen of te rebasen.
  • Gebruik vertakkingen om uw wijzigingen te isoleren. Branches zijn goedkoop en privé en samenvoegen is eenvoudig. U kunt ook een back-up maken van wijzigingen in een vertakking door deze naar de server te pushen.
  • Gebruik een naamgevingsconventie bij het publiceren van onderwerptakken. Geef de branch een naam users/<alias>/<branchname>. Deze naam helpt bij het groeperen van uw takken en maakt het gemakkelijk voor anderen om de eigenaar te identificeren.
  • Vergeet niet om uw wijzigingen te pushen. Gebruiken Commit != Checkin en (Commit + Push) == Checkin.
  • Overweeg het gebruik .gitignore voor grote binaire bestanden, zodat ze niet worden toegevoegd aan de opslagplaats. Zie Bestanden negeren voor meer informatie.
  • Overweeg nuGet- of Team Foundation Server-versiebeheer te gebruiken om uw grote binaire bestanden op te slaan.

Dingen die moeten worden vermeden

  • Rebase niet nadat je hebt gepusht. Het rebasen van gepushte commits in Git kan slecht zijn, omdat iedereen in de opslagplaats hun lokale wijzigingen opnieuw moet rebasen. Teamleden zijn mogelijk niet tevreden als ze deze taak moeten uitvoeren. Het opnieuw maken van gepushte doorvoeringen op uw eigen persoonlijke vertakking, zelfs als ze worden gepusht, is geen probleem, tenzij anderen deze doorvoeringen ophalen.
  • Voer geen binaire bestanden door naar uw opslagplaats. Git comprimeert binaire bestanden niet op de manier die Team Foundation-versiebeheer doet. Omdat alle repositories de volledige geschiedenis hebben, betekent het doorvoeren van binaire bestanden een permanente toename van opslagruimte.

Samenvatting

Soms worden ongewenste elementen, zoals grote bestanden, toegevoegd aan een opslagplaats en moeten ze worden verwijderd om de opslagplaats schoon en licht te houden. U kunt deze taak uitvoeren door uw lokale repository gereed te maken. Gebruik de git rebase opdracht en gebruik vervolgens de git push --force opdracht om de serveropslagplaats te overschrijven met uw lokale opslagplaats.

  • Last updated on