Vereiste invoer:
- Lees, volg en begrijp mijn artikel over Git . Dit zal helpen ervoor te zorgen dat alles is ingesteld en klaar is voor gebruik.
- Installeer IntelliJ IDEA.
- Wijs een uur persoonlijke tijd toe om volledig meesterschap te bereiken.
Kloon het project lokaal
Er zijn hier twee opties:- 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.
- Kloon mijn repository en doe alles lokaal zonder de mogelijkheid om alles naar de server te pushen. Dit is tenslotte mijn archief :)
-
Kopieer het projectadres:
-
Open IntelliJ IDEA en selecteer "Get from Version Control":
-
Kopieer en plak het projectadres:
-
U wordt gevraagd om een IntelliJ IDEA-project te maken. Accepteer het aanbod:
-
Aangezien er geen build-systeem is en dat buiten het bestek van dit artikel valt, selecteren we Maak project van bestaande bronnen :
-
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:- CTRL+T — Haal de laatste wijzigingen op uit de externe repository (git pull).
- 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).
- 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).
- 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?-
Haal alle huidige wijzigingen op in de hoofdtak (bijvoorbeeld "master").
-
Maak vanuit deze hoofdtak een aparte tak voor uw werk.
-
Implementeer de nieuwe functionaliteit.
-
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).
- Push uw wijzigingen naar de externe repository.
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.-
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:- accepteer de jouwe - accepteer alleen wijzigingen van readme-improver.
- accepteer die van hen - accepteer alleen wijzigingen van master.
- samenvoegen — kies zelf wat u wilt behouden en wat u wilt weggooien.
- Dit zijn de wijzigingen van readme-improver.
- Het samengevoegde resultaat. Voor nu is het wat er was vóór de veranderingen.
- De wijzigingen van de hoofdtak.
GO TO FULL VERSION