Veelgestelde vragen over Git

Controleer eerst of u een origin opslagplaats hebt geconfigureerd. U moet dit hebben als u uw opslagplaats hebt gekloond met behulp van git clone. Wanneer u een vertakking uitcheckt die niet lokaal bestaat, controleert Git of er een externe vertakking met dezelfde naam is. Als dat zo is, maakt Git een lokale vertakking die verwijst naar de externe vertakking. Gebruik git pull dit om de doorvoeringen te downloaden en de vertakkingsgeschiedenis lokaal bij te werken.

Voer git branch zonder argumenten uit om de lokale vertakkingen weer te geven en markeer de vertakking die u hebt uitgecheckt. In Visual Studio wordt op de statusbalk ook de huidige vertakking weergegeven wanneer u werkt met een project dat is opgeslagen in een lokale Git-opslagplaats.

Het is raadzaam afzonderlijke doorvoeringen aan te brengen voor logisch afzonderlijke wijzigingen. U kunt doorvoeringen beschouwen als vermeldingen in een logboekboek. Wanneer u een wijziging aanbrengt die de moeite waard is om te noteren, moet u deze opnemen in een doorvoering. Een populaire benadering is om frequente lokale doorvoeringen toe te staan, maar door middel van herbasing voordat ze worden gepusht. Dit biedt flexibiliteit terwijl de doorvoergeschiedenis gestroomlijnd blijft.

Grote projecten met veel doorvoeringen en inzenders kunnen resulteren in een main vertakkingsgeschiedenis die de ontwikkeling van onderwerptakken meer weerspiegelt dan het totale project. Met Git kunt u doorvoeringen op vertakkingen condenseren door middel van verpletterende doorvoeringen en rebasing. Als u doorvoeringen verplettert, wordt de vertakkingsgeschiedenis minder uitgebreid, waardoor de doorvoergeschiedenis van de hoofdvertakking wordt vereenvoudigd zodra deze is samengevoegd.

Gebruik de git blame opdracht om erachter te komen wie een bepaalde wijziging heeft aangebracht in een bestand. Vanuit uw lokale opslagplaats kunt u uitvoeren git blame met de -L parameter, waarbij u opgeeft welke regels van belang zijn. Blame produceert opgemaakte uitvoer met de doorvoering die de regel voor het laatst heeft bijgewerkt en de naam van de persoon die de doorvoering heeft gemaakt.

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame doorzoekt de doorvoergeschiedenis voor u. U kunt ook de geschiedenis van een bestand bekijken in de webportal om te bepalen wie een wijziging heeft aangebracht en wanneer. Open Code Explorer voor uw opslagplaats en vertakking en selecteer vervolgens het gewenste bestand. Azure-opslagplaatsen tonen een volledige doorvoergeschiedenis voor dat bestand in de huidige vertakking.

Uitchecken naar een andere vertakking in Git is van invloed op de status van bestanden op uw bestandssysteem. Git gebruikt de doorvoergeschiedenis om ervoor te zorgen dat u werkt met de bestanden die de status van uw vertakking vertegenwoordigen. Als u vertakkingen probeert te wijzigen terwijl u niet-doorgevoerde wijzigingen hebt, worden deze wijzigingen tijdens het uitchecken overschreven. Omdat Git niet wilt dat u per ongeluk uw wijzigingen kwijtraakt, voorkomt u dat het uitchecken plaatsvindt. U hebt twee opties:

• Laat de wijzigingen los en ga terug naar de meest recente doorvoering. Zie wijzigingen ongedaan maken in Git voor instructies over het terugdraaien naar de meest recente doorvoer.
• Voer de wijzigingen door. Bekijk hoe u uw werk opslaat in Git met doorvoeringen.
• Uw huidige werk opschonen , de wijzigingen opslaan voor later gebruik en de werkruimte opschonen tot de laatste doorvoering.

Dit probleem heeft betrekking op samenvoegingsconflicten in grote binaire bestanden. De huidige limiet voor bestanden is 100 MB. De tijdelijke oplossing is om samenvoegingsconflicten lokaal op te lossen door het doel lokaal samen te voegen in de bron, conflicten op te lossen en de wijzigingen te pushen.

Git LFS (Large File Storage) wordt aanbevolen voor het opslaan van grote binaire bestanden, niet alleen om conflicten te voorkomen, maar ook om de totale grootte van de opslagplaats te beheren, wat van invloed is op kloon- en pushtijden.

Als u uw wijzigingen wilt opslaan zonder deze door te voeren, gebruikt u Git stash. Met Stash worden de huidige gefaseerde en niet-klaargezette wijzigingen in uw vertakking opgeslagen en wordt de vertakking teruggezet naar de status van de laatste doorvoering. U kunt vervolgens overschakelen naar een andere vertakking, uw werk doen en later uitvoeren stash apply om uw wijzigingen te herstellen.

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

Wanneer u [git stash apply] uitvoert, worden de laatst opgeslagen wijzigingen toegepast op uw huidige vertakking. Als er een conflict is, herstelt [stash] de wijzigingen voor de bestanden die niet conflicteren en worden conflictmarkeringen gemaakt in de bestanden die dat wel doen. In dit geval moet u de wijzigingen handmatig samenvoegen.

Wanneer u klaar bent met de stash, verwijdert u deze met [git stash drop]. Met deze opdracht verwijdert u de laatste set wijzigingen die zijn opgeslagen.

U kunt meerdere stashes hebben, maar het beheren ervan vereist meer handmatige manipulatie omdat u expliciet stashes moet toepassen en neerzetten. Meer informatie vindt u in de Git Stash-documentatie.

Git maakt standaard gebruik van een opdrachtregeleditor bij het vragen om doorvoerberichten, het uitvoeren van nieuwe basisbewerkingen en ander werk waarvoor aanvullende informatie nodig is. De standaardeditor is geconfigureerd met behulp van git config:

> git config core.editor _path_to_editor_ _options_to_editor_

Met Git voor Windows kunt u Kladblok eenvoudig instellen als editor:

> git config core.editor notepad

Met deze opdracht configureert u Windows Kladblok om waar nodig Git-gegevens te bewerken en de tekst van Git naar Kladblok correct door te geven. U kunt ook opgeven

> git config format.commitMessageColumns 72 

Als u de tekstkolommen in de doorvoerberichten naar de voorkeur 72 en regelterugloop wilt behouden nadat u die tekenlimiet op een regel hebt bereikt.

Git plaatst een gebruikersnaam en e-mailadres in elke doorvoer en Azure-opslagplaatsen gebruiken deze informatie bij het weergeven van doorvoeringen en bij het werken met pull-aanvragen. Als u aan de opdrachtregel werkt, kunt u de naam en e-mailgegevens bijwerken die worden weergegeven met behulp van de git config opdracht:

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

Met de --global optie stelt u het e-mailadres en de naam in die zijn opgenomen in doorvoeringen voor alle Git-opslagplaatsen op dit systeem. Als u de instellingen voor één opslagplaats wilt wijzigen, moet u de map waarin de Git-opslagplaats zich bevindt, wijzigen en de bovenstaande opdrachten uitvoeren zonder de --global vlag.

U kunt ook de naam- en e-mailinstellingen van Visual Studio wijzigen. Selecteer in het Git-menu Instellingen in het dialoogvenster Opties de optie Algemene instellingen voor Git of Algemene instellingen voor> Git-opslagplaatsen.

Visual Studio 2019 versie 16.8 en nieuwere versies biedt een Git-versiebeheerervaring met behoud van de Git-gebruikersinterface van Team Explorer . Als u Team Explorer wilt gebruiken, schakelt u Extra Opties>Preview-functies>>nieuwe Git-gebruikerservaring uit in de menubalk. U kunt Git-functies van beide interfaces door elkaar oefenen.

Kies In Team Explorer instellingen en selecteer onder Git de koppeling Algemene instellingen of Opslagplaatsinstellingen .