Een match made in heaven: Git en IntelliJ IDEA

Vasthoudend aan de gevestigde traditie, begroet ik u als toekomstige senior software-ingenieurs. Het artikel van vandaag is de logische uitbreiding van mijn artikel over Git . In het artikel over Git heb ik beschreven hoe je met Git werkt op de opdrachtregel. Vandaag laat ik je zien hoe je het allemaal kunt doen in IntelliJ IDEA. Aan het begin van mijn reis als ontwikkelaar gebruikte ik de opdrachtregel en dacht dat ik hiervoor geen GUI nodig had. Alles was immers duidelijk zoals het was... Maar dat was tot het moment dat ik Git in IntelliJ IDEA ging gebruiken... Vanaf het begin wil ik zeggen dat ik mijn persoonlijke ervaring beschrijf. Er zijn verschillende manieren om een ​​bepaald probleem in IntelliJ IDEA op te lossen. Als je een betere manier weet dan wat ik in het artikel zal beschrijven, schrijf het dan in de comments en we zullen het bespreken.

Vereiste invoer:

1. Lees, volg en begrijp mijn artikel over Git . Dit zal helpen ervoor te zorgen dat alles is ingesteld en klaar is voor gebruik.
2. Installeer IntelliJ IDEA.
3. Wijs een uur persoonlijke tijd toe om volledig meesterschap te bereiken.

Laten we werken met het demoproject dat ik heb gebruikt voor het artikel over Git. UPDATE:Op het moment van publicatie zal de nieuwe GitHub-gebruikersinterface beschikbaar zijn en zullen sommige pictogrammen niet staan ​​waar ze in het artikel worden weergegeven. Wees niet gealarmeerd: u hoeft alleen niet over te schakelen naar de nieuwe gebruikersinterface of ernaar te zoeken.

Kloon het project lokaal

Er zijn hier twee opties:

1. Als je al een GitHub-account hebt en later iets wilt pushen, is het beter om het project te splitsen en je eigen exemplaar te klonen.
2. Kloon mijn repository en doe alles lokaal zonder de mogelijkheid om alles naar de server te pushen. Dit is tenslotte mijn archief :)

Om een ​​project van GitHub te klonen, moet u de projectlink kopiëren en doorgeven aan IntelliJ IDEA:

1. Kopieer het projectadres:

2. Open IntelliJ IDEA en selecteer "Get from Version Control":

3. Kopieer en plak het projectadres:

4. U wordt gevraagd om een ​​IntelliJ IDEA-project te maken. Accepteer het aanbod:

5. Aangezien er geen build-systeem is en dat buiten het bestek van dit artikel valt, selecteren we Maak project van bestaande bronnen :

6. Vervolgens zie je dit prachtige scherm: Nu we het klonen door hebben, kun je eens rondkijken.

Eerste blik op IntelliJ IDEA als Git UI

Bekijk het gekloonde project eens nader: u kunt al veel informatie krijgen over het versiebeheersysteem. Ten eerste hebben we het deelvenster Versiebeheer in de linkerbenedenhoek. Hier kun je alle lokale wijzigingen vinden en een lijst met commits krijgen (analoog aan "git log"). Laten we verder gaan met een bespreking van Log . Er is een bepaalde visualisatie die ons helpt om precies te begrijpen hoe de ontwikkeling is verlopen. Je kunt bijvoorbeeld zien dat er een nieuwe branch is gemaakt met een toegevoegde header voor txt commit, die vervolgens is samengevoegd in de master branch. Als je op een commit klikt, zie je in de rechterhoek alle informatie over de commit: alle wijzigingen en metadata.Bovendien kunt u de daadwerkelijke wijzigingen zien. We zien ook dat daar een conflict is opgelost. IDEA presenteert dit ook heel goed. Als je dubbelklikt op het bestand dat tijdens deze commit is gewijzigd, zullen we zien hoe het conflict is opgelost: We merken op dat we links en rechts de twee versies van hetzelfde bestand hebben die moesten worden samengevoegd tot één. En in het midden hebben we het uiteindelijke samengevoegde resultaat. Als een project veel branches, commits en gebruikers heeft, moet je apart zoeken op branch, gebruiker en datum: Het laatste wat ik wil uitleggen voordat we beginnen, is hoe je kunt begrijpen in welke branch we zitten. een minuut om het uit te zoeken... Heb je het gevonden? Geef op? :D In de rechter benedenhoek is er een knop met het label Git: master. Wat volgt op "Git:" is de huidige branch. Als u op de knop klikt, kunt u veel nuttige dingen doen: overschakelen naar een andere tak, een nieuwe aanmaken, een bestaande hernoemen, enzovoort.

Werken met een archief

Handige sneltoetsen

Voor toekomstig werk moet u een paar zeer nuttige sneltoetsen onthouden:

0. CTRL+T — Haal de laatste wijzigingen op uit de externe repository (git pull).
1. CTRL+K — Maak een commit / bekijk alle huidige wijzigingen. Dit omvat zowel niet-gevolgde als gewijzigde bestanden (zie mijn artikel over git, waarin dit wordt uitgelegd) (git commit).
2. CTRL+SHIFT+K — Dit is de opdracht voor het pushen van wijzigingen naar de externe repository. Alle commits die lokaal zijn gemaakt en nog niet in de externe repository staan, worden gepusht (git push).
3. ALT+CTRL+Z — Wijzigingen in een specifiek bestand terugdraaien naar de status van de laatste commit die in de lokale repository is gemaakt. Als u het hele project in de linkerbovenhoek selecteert, kunt u wijzigingen in alle bestanden ongedaan maken.

Wat willen we?

Om werk gedaan te krijgen, moeten we een basisscenario beheersen dat overal wordt gebruikt. Het doel is om nieuwe functionaliteit in een aparte branch te implementeren en deze vervolgens naar een externe repository te pushen (dan moet je ook een pull request naar de hoofdbranch maken, maar dat valt buiten het bestek van dit artikel). Wat is er nodig om dit te doen?

1. Haal alle huidige wijzigingen op in de hoofdtak (bijvoorbeeld "master").

2. Maak vanuit deze hoofdtak een aparte tak voor uw werk.

3. Implementeer de nieuwe functionaliteit.

4. Ga naar de hoofdvestiging en controleer of er tijdens het werken nieuwe wijzigingen zijn aangebracht. Zo niet, dan is alles in orde. Maar als er wijzigingen zijn, dan doen we het volgende: ga naar de werktak en rebase de wijzigingen van de hoofdtak naar de onze. Als alles goed gaat, dan geweldig. Maar het is heel goed mogelijk dat er conflicten ontstaan. Ze kunnen namelijk gewoon van tevoren worden opgelost, zonder tijd te verspillen in de externe repository.

   Vraag je je af waarom je dit zou moeten doen? Het is netjes en voorkomt dat er conflicten ontstaan ​​nadat je je branch naar de lokale repository hebt gepusht (er is natuurlijk een mogelijkheid dat er nog steeds conflicten zullen optreden, maar het wordt veel kleiner).

5. Push uw wijzigingen naar de externe repository.

Wat daarna komt, hangt af van uw taken en uw verbeeldingskracht.

Wijzigingen ophalen van de externe server?

Ik heb een beschrijving toegevoegd aan de README met een nieuwe commit en wil deze wijzigingen krijgen. Als er zowel in de lokale repository als in de externe repository wijzigingen zijn aangebracht, worden we uitgenodigd om te kiezen tussen een samenvoeging en een rebase. We kiezen ervoor om te fuseren. Voer CTRL+T in : U kunt nu zien hoe de README is veranderd, dwz de wijzigingen van de externe repository zijn binnengehaald, en in de rechter benedenhoek kunt u alle details zien van de wijzigingen die van de server kwamen.

Maak een nieuwe branch op basis van master

Alles is hier eenvoudig.

1. Ga naar de rechter benedenhoek en klik op Git: master . Selecteer + Nieuwe tak .

Laat het Checkout filiaal aangevinkt en voer de naam van het nieuwe filiaal in. Voor mij zal het leesmij-verbeteraar zijn .

Git: master verandert dan in Git: readme-improver .

Laten we parallel werk simuleren

Om conflicten te laten verschijnen, moet iemand ze aanmaken :D Ik zal de README bewerken met een nieuwe commit via de browser, waardoor parallel werk wordt gesimuleerd. Het is alsof iemand wijzigingen heeft aangebracht in hetzelfde bestand terwijl ik eraan werkte. Het resultaat zal een conflict zijn. Ik zal het woord "fully" van regel 10 verwijderen.

Implementeer onze functionaliteit

Onze taak is om de README te wijzigen en een beschrijving aan het nieuwe artikel toe te voegen. Dat wil zeggen, het werk in Git gaat via IntelliJ IDEA. Voeg dit toe: De wijzigingen zijn doorgevoerd. Nu kunnen we een commit maken. Druk op CTRL+K , wat ons het volgende geeft: Voordat we een commit maken, moeten we goed kijken naar wat dit venster te bieden heeft. Ik heb rode pijlen toegevoegd om je te laten zien waar je moet zoeken. Er zijn hier veel interessante dingen. In de sectie Commit-bericht schrijven we tekst die is gekoppeld aan de commit. Om het vervolgens te maken, moeten we op Vastleggen klikken. Ik heb nog steeds niet ontdekt hoe ik dit met een sneltoets moet doen. Als iemand erachter komt hoe, schrijf me dan alsjeblieft - dat zou me erg blij maken. We schrijven dat de README is gewijzigd en maken de commit aan. Er verschijnt een waarschuwing in de linker benedenhoek met de naam van de commit:

Controleer of de hoofdvestiging is gewijzigd

We hebben onze taak volbracht. Het werkt. We hebben testen geschreven. Alles is in orde. Maar voordat we naar de server pushen, moeten we nog steeds controleren of er in de tussentijd wijzigingen zijn opgetreden in de hoofdtak. Hoe kon dat gebeuren? Heel eenvoudig: iemand krijgt een taak na jou, en die iemand maakt deze sneller af dan jij jouw taak afmaakt. We moeten dus naar de master branch gaan. Om dit te doen, moeten we doen wat wordt getoond in de rechter benedenhoek in de onderstaande schermafbeelding: Druk in de master branch op CTRL+T om de laatste wijzigingen van de externe server te krijgen. Als je kijkt naar wat er verandert, kun je gemakkelijk zien wat er is gebeurd:Het woord "fully" is verwijderd. Misschien heeft iemand van marketing besloten dat het niet zo geschreven mocht worden en heeft hij de ontwikkelaars de taak gegeven om het bij te werken. We hebben nu een lokale kopie van de laatste versie van de master branch. Ga terug naar leesmij-verbeteraar . Nu moeten we de wijzigingen van de master branch rebaseen naar de onze. We doen dit: Als je alles correct hebt gedaan en met mij hebt gevolgd, zou het resultaat een conflict in het README-bestand moeten laten zien: Hier hebben we ook veel informatie om te begrijpen en op te nemen. Hier wordt een lijst weergegeven met bestanden (in ons geval één bestand) die conflicten hebben. We kunnen kiezen uit drie opties:

1. accepteer de jouwe - accepteer alleen wijzigingen van readme-improver.
2. accepteer die van hen - accepteer alleen wijzigingen van master.
3. samenvoegen — kies zelf wat u wilt behouden en wat u wilt weggooien.

Het is niet duidelijk wat er is veranderd. Als er wijzigingen zijn in de master branch, moeten ze daar nodig zijn, dus we kunnen onze wijzigingen niet zomaar accepteren. Dienovereenkomstig selecteren we samenvoegen : hier kunnen we zien dat er drie delen zijn:

1. Dit zijn de wijzigingen van readme-improver.
2. Het samengevoegde resultaat. Voor nu is het wat er was vóór de veranderingen.
3. De wijzigingen van de hoofdtak.

We moeten een samengevoegd resultaat produceren dat iedereen tevreden zal stellen. Als we bekijken wat er VOOR onze wijzigingen is gewijzigd, realiseren we ons dat ze simpelweg het woord "fully" hebben verwijderd. Oke geen probleem! Dat betekent dat we het ook in het samengevoegde resultaat zullen verwijderen en vervolgens onze wijzigingen zullen toevoegen. Nadat we het samengevoegde resultaat hebben gecorrigeerd, kunnen we op Toepassen klikken . Dan verschijnt er een melding die ons vertelt dat de rebase succesvol was: Daar! We hebben ons eerste conflict opgelost via IntelliJ IDEA :D

Push wijzigingen naar de externe server

De volgende stap is om de wijzigingen naar de externe server te pushen en een pull-aanvraag te maken. Om dit te doen, drukt u gewoon op CTRL+SHIFT+K . Dan krijgen we: Aan de linkerkant zal er een lijst zijn met commits die niet naar de externe repository zijn gepusht. Aan de rechterkant staan ​​alle bestanden die zijn gewijzigd. En dat is het! Druk op Push en je zult geluk ervaren :) Als de push succesvol is, zie je een melding zoals deze in de rechter benedenhoek:

Bonusgedeelte

In eerste instantie wilde ik de creatie van een pull-request niet toevoegen aan dit artikel, maar het is niet helemaal compleet zonder. Laten we dus naar een GitHub-repository gaan (een die natuurlijk van jou is :)) en we zien dat GitHub al weet wat we willen: klik op Compare & pull request . Klik vervolgens op Pull-aanvraag maken . Omdat we de conflicten van tevoren hebben opgelost, kunnen we deze nu bij het maken van een pull-aanvraag meteen samenvoegen: En dat is alles wat ik deze keer wilde zeggen. Natuurlijk heb ik de deur maar een klein stukje voor je opengezet en je een klein stukje laten zien. Je leert over de rest als je het nodig hebt. Ik heb de gewoonte om je uit te nodigen om mij te volgen op GitHub, waar ik mijn projecten plaats met verschillende technologieën die ik op het werk gebruik. Ik heb onlangs een persoonlijke prestatie geleverd: een van mijn projecten kreeg sterren van meer dan honderd ontwikkelaars. Er is een ongelooflijk gevoel van vreugde als je weet dat wat je hebt gedaan door iemand anders wordt gebruikt. En het voorgoed gebruiken.

Handige links

1. CodeGym: Aan de slag met Git: een uitgebreide gids voor nieuwkomers
2. GitHub: demoproject om te oefenen
3. JetBrains: stel een Git-repository in
4. GitHub: Mijn account