Share
Eenvoudig gezegd, een externe repository is er een die niet van jezelf is. Het kan op een centrale server zijn, op een pc van een andere ontwikkelaar, of zelfs op uw bestandssysteem. Zolang je er toegang toe hebt via een soort netwerkprotocol, maakt Git het ongelooflijk gemakkelijk om bijdragen te delen met andere repositories.
De belangrijkste rol van externe repositories is om andere ontwikkelaars binnen uw eigen repository te vertegenwoordigen. Bijkantoren zouden daarentegen alleen moeten omgaan met projectontwikkeling. Dat wil zeggen, probeer niet elke ontwikkelaar zijn of haar eigen filiaal te laten bewerken - geef elk een complete repository en reserveert vestigingen voor het ontwikkelen van functies.
Dit hoofdstuk begint met een bespreking van de werking van afstandsbedieningen en presenteert vervolgens de twee meest voorkomende workflows van Git-gebaseerde samenwerking: de gecentraliseerde workflow en de workflow van de integrator.
Gelijkwaardig aan git branch, de Git remote commando wordt gebruikt om verbindingen met andere repositories te beheren. Afstandsbedieningen zijn niets meer dan bladwijzers naar andere opslagplaatsen - in plaats van het volledige pad in te voeren, kunt u ernaar verwijzen met een gebruiksvriendelijke naam. We zullen leren hoe we deze bladwijzers kunnen gebruiken binnen Git Below.
U kunt uw bestaande afstandsbedieningen bekijken door het Git remote opdracht zonder argumenten:
Git remote
Als u geen afstandsbedieningen hebt, geeft dit commando geen informatie weer. Als je het hebt gebruikt git clone om je repository te krijgen, zie je een oorsprong afstandsbediening. Git voegt deze verbinding automatisch toe, in de veronderstelling dat je er onderweg waarschijnlijk mee wilt communiceren.
U kunt een beetje meer informatie over uw afstandsbedieningen aanvragen bij de -v vlag:
git remote -v
Dit toont het volledige pad naar de repository. Het specificeren van externe paden wordt besproken in de volgende sectie.
De git remote add command maakt een nieuwe verbinding met een externe repository.
git remote add
Na het uitvoeren van deze opdracht kunt u de Git-repository bereiken op
Git accepteert veel netwerkprotocollen voor het specificeren van de locatie van een externe repository, inclusief het dossier://, ssh: //, http: //, en zijn gewoonte git: // protocol. Bijvoorbeeld:
git remote add some-user ssh: //[email protected]/some-user/some-repo.git
Na het uitvoeren van deze opdracht hebt u toegang tot de repository op github.com/some-user/some-repo.git alleen gebruiken Bepaalde door de gebruiker. Sinds we hebben gebruikt ssh: // als het protocol, wordt u waarschijnlijk om een SSH-wachtwoord gevraagd voordat u iets mag doen met het account. Dit maakt SSH een goede keuze om schrijftoegang te verlenen aan ontwikkelaars, terwijl HTTP-paden over het algemeen worden gebruikt om alleen-lezen toegang te geven. Zoals we snel zullen ontdekken, is dit ontworpen als een beveiligingsfunctie voor gedistribueerde omgevingen.
Ten slotte kunt u een externe verbinding verwijderen met de volgende opdracht:
git remote rm
Commits kunnen de atomaire eenheid van Git-gebaseerde versiebeheer zijn, maar takken zijn het medium waarin remote repositories communiceren. Remote takken handelen zoals de lokale afdelingen die we tot nu toe hebben behandeld, behalve dat ze een filiaal vertegenwoordigen in de repository van iemand anders.
Nadat u een externe branch hebt gedownload, kunt u deze inspecteren, samenvoegen en uitbreiden zoals elke andere branch. Dit zorgt voor een zeer korte leercurve als je begrijpt hoe je takken lokaal gebruikt.
De handeling om takken van een andere repository te downloaden wordt aangeroepen ophalen. Om een remote branch op te halen, kunt u de repository en de branch specificeren die u zoekt:
git fetch
Of, als u wilt downloaden elk filiaal in -r optie om git branch:
git branch -r
Dit geeft je een filiaallijst die er ongeveer zo uitziet:
oorsprong / hoofdoorsprong / oorsprong van een kenmerk / een ander kenmerk
Remote branches worden altijd voorafgegaan door de naam van de remote (oorsprong/) om ze te onderscheiden van lokale vestigingen.
Onthoud dat Git remote repositories gebruikt als bladwijzers-geen realtime verbindingen met andere repositories. Remote branches zijn kopieën van de lokale vestigingen van een andere repository. Buiten de feitelijke ophaalactie zijn opslagruimten volledig geïsoleerde ontwikkelingsomgevingen. Dit betekent ook dat Git takken nooit automatisch ophaalt om toegang te krijgen tot bijgewerkte informatie - u moet dit handmatig doen.
Maar dit is een goede zaak, omdat het betekent dat u zich niet voortdurend zorgen hoeft te maken over wat anderen eraan bijdragen terwijl u aan het werk bent. Dit is alleen mogelijk vanwege de niet-lineaire workflow die is ingeschakeld door Git-vestigingen.
Voor alle doeleinden en doeleinden gedragen remote branches zich als alleen-lezen branches. Je kunt hun geschiedenis veilig bekijken en hun commits bekijken via git uitchecken, maar je kunt ze niet blijven ontwikkelen voordat je ze in je lokale repository integreert. Dit is logisch als je bedenkt dat remote branches zijn kopieën van commits van andere gebruikers.
De ... syntaxis is erg handig voor het filteren van loggeschiedenis. Met de volgende opdracht worden bijvoorbeeld nieuwe updates weergegeven van origin / master die niet bij u in de buurt zijn meester tak. Het is over het algemeen een goed idee om dit uit te voeren voordat u wijzigingen samenvoegt, zodat u precies weet wat u aan het integreren bent:
git log master ... origin / master
Als dit enige commits oplevert, betekent dit dat u achter het officiële project staat en dat u waarschijnlijk uw repository zou moeten bijwerken. Dit wordt beschreven in de volgende sectie.
Het is mogelijk om afgelegen vestigingen af te rekenen, maar het zal je in een onthechting plaatsen HOOFD staat. Dit is veilig voor het bekijken van de wijzigingen van andere gebruikers voordat ze worden geïntegreerd, maar alle wijzigingen die u toevoegt, zullen verloren gaan, tenzij u een nieuw lokaal filiaalpunt maakt om ernaar te verwijzen.
Natuurlijk is het hele punt van ophalen het integreren van de resulterende externe vestigingen in uw lokale project. Stel dat u bijdraagt aan een open-sourceproject en dat u hebt gewerkt aan een functie genaamd sommige-functie. Als het "officiële" project (meestal aangeduid door oorsprong) gaat verder, u wilt mogelijk zijn nieuwe commits opnemen in uw repository. Dit zou ervoor zorgen dat uw functie nog steeds werkt met de nieuwste ontwikkelingen.
Gelukkig kunt u exact hetzelfde gebruiken git fuseren opdracht om wijzigingen op te nemen van origin / master in uw featurentak:
git checkout some-feature git fetch origin git merge origin / master
Aangezien je geschiedenis is uiteengevallen, resulteert dit in een drievoudige samenvoeging, waarna je sommige-functie branch heeft toegang tot de meest actuele versie van het officiële project.
Accentsconagua
meester in een functietak Echter vaak samenvoegen met origin / master alleen al het ophalen van updates resulteert uiteindelijk in een geschiedenis bezaaid met zinloze samenvoegingsopdrachten. Afhankelijk van hoe nauwkeurig uw functie moet zijn om de rest van de codebasis te volgen, kan rebasen een betere manier zijn om wijzigingen te integreren:
git checkout some-feature git fetch oorsprong git rebase origin / master
Net als bij lokale rebasing creëert dit een perfect lineaire geschiedenis zonder overbodige merge-commits:
meester Het rebasen / samenvoegen van remote branches heeft precies dezelfde trade-offs als besproken in het hoofdstuk over lokale vestigingen.
Omdat de fetch / merge-volgorde zo vaak voorkomt in gedistribueerde ontwikkeling, biedt Git een Trekken commando als een handige sneltoets:
git pull origin / master
Hiermee wordt de hoofdtak van de oorsprong opgehaald en vervolgens in één stap samengevoegd in de huidige vertakking. Je kunt ook de --rebase optie om te gebruiken git rebase in plaats van git fuseren.
Om de git fetch commando, Git biedt ook een Duwen commando. Duwen is bijna het tegenovergestelde van ophalen in die pakkende importfilialen, terwijl exportvertalingen naar een andere repository worden geduwd.
git push
Het bovenstaande commando stuurt de lokale git push creëert een lokaal tak. Bijvoorbeeld uitvoeren git push mary my-feature in je lokale repository ziet het er vanuit het perspectief van Mary uit (je repository zal niet worden beïnvloed door de push).
Let erop dat mijn-functie is een lokaal filiaal in de repository van Mary, terwijl het een afgelegen tak had ze het zelf gehaald.
Dit maakt het indrukken van een gevaarlijke operatie. Stel je voor dat je je ontwikkelt in je eigen lokale repository, wanneer ineens een nieuwe lokale filiaal uit het niets verschijnt. Maar de repositories zouden moeten dienen als volledig geïsoleerde ontwikkelingsomgevingen, dus waarom zou dat wel git push zelfs bestaan? Zoals we binnenkort zullen ontdekken, is duwen een noodzakelijke tool voor het onderhouden van openbare Git-archieven.
Nu we een basisidee hebben van hoe Git interageert met andere repositories, kunnen we de real-world workflows bespreken die door deze commando's worden ondersteund. De twee meest gebruikte samenwerkingsmodellen zijn: de gecentraliseerde workflow en de integratorworkflow. Gebruikers van SVN en CVS moeten redelijk op hun gemak zijn met Git's smaak van gecentraliseerde ontwikkeling, maar met Git kun je ook gebruikmaken van de zeer efficiënte merge-mogelijkheden. De integratorworkflow is een typisch gedistribueerd samenwerkingsmodel en is niet mogelijk in puur gecentraliseerde systemen.
Let tijdens het lezen van deze workflows op dat Git alle opslagplaatsen behandelt als gelijken. Er is geen "master" repository volgens Git zoals er is met SVN of CVS. De "officiële" codebasis is slechts een projectconventie - de enige reden dat het de officiële repository is, want daar is iedereen oorsprong externe punten.
Elk samenwerkingsmodel omvat minstens één openbaar repository die dient als een point-of-entry voor meerdere ontwikkelaars. Openbare archieven hebben de unieke beperking om te zijn kaal-ze mogen geen werkmap hebben. Dit voorkomt dat ontwikkelaars elkaars werk per ongeluk overschrijven git push. U kunt een bare repository maken door de --kaal optie om git init:
git init - vers
Publieke repositories zouden alleen moeten functioneren als opslagfaciliteiten-geen ontwikkelomgevingen. Dit wordt overgebracht door het toevoegen van een .git uitbreiding naar het bestandspad van de repository, omdat de interne repository-database zich in de projectroot bevindt in plaats van de .git subdirectory. Een compleet voorbeeld kan er dus als volgt uitzien:
git init --bare some-repo.git
Afgezien van het ontbreken van een werkmap, is er niets bijzonders aan een bare repository. U kunt verbindingen op afstand toevoegen, erop drukken en er op de gebruikelijke manier uithalen.
De gecentraliseerde workflow is het meest geschikt voor kleine teams waarbij elke ontwikkelaar schrijftoegang heeft tot de repository. Het maakt samenwerking mogelijk door gebruik te maken van één centrale repository, net zoals de SVN- of CVS-workflow. In dit model, allemaal Wijzigingen moeten worden gedeeld via de centrale opslagplaats, die meestal op een server wordt opgeslagen om samenwerking op internet mogelijk te maken.
Ontwikkelaars werken individueel in hun eigen lokale repository, die volledig geïsoleerd is van alle anderen. Zodra ze een functie hebben voltooid en klaar zijn om hun code te delen, maken ze deze schoon en integreren ze deze in hun lokale omgeving meester, en druk het naar de centrale repository (bijv., oorsprong). Dit betekent ook dat elke ontwikkelaar SSH-toegang tot de centrale repository nodig heeft.
Daarna kunnen alle anderen de nieuwe commits ophalen en ze opnemen in hun lokale projecten. Nogmaals, dit kan worden gedaan met een samenvoeging of een rebase, afhankelijk van de conventies van je team.
Dit is het kernproces achter gecentraliseerde workflows, maar het raakt een hobbel wanneer meerdere gebruikers tegelijkertijd proberen de centrale repository bij te werken. Stel je een scenario voor waarin twee ontwikkelaars een functie hebben voltooid, samengevoegd in hun lokale meester, en probeerde het tegelijkertijd te publiceren (of er dichtbij).
Degene die als eerste op de server komt, kan zijn commits normaal duwen, maar dan komt de tweede ontwikkelaar met een uiteenlopende geschiedenis te zitten en kan Git geen snel vooruitspoelende fusie uitvoeren. Als een ontwikkelaar met de naam John bijvoorbeeld zijn wijzigingen vlak voor Mary zou doorvoeren, zouden we een conflict zien in de repository van Mary:
De enige manier om het te maken oorsprong's meester (bijgewerkt door John) match Mary's meester is om beschrijven John's commit. Uiteraard zou dit erg slecht zijn, dus Git breekt het pushen en uitvoeren van een foutbericht af:
! [afgewezen] master -> master (niet-fast-forward) fout: kan sommige refs niet pushen naar 'some-repo.git'
Om deze situatie te verhelpen, moet Mary synchroniseren met de centrale repository. Dan zal ze haar veranderingen op de gebruikelijke manier kunnen pushen.
git fetch origin master git rebase origin / master git push origin master
Afgezien daarvan is de gecentraliseerde workflow relatief eenvoudig. Elke ontwikkelaar blijft in zijn of haar eigen lokale repository en trekt periodiek naar de centrale repository om alles up-to-date te houden. Het is een handige workflow om in te stellen, omdat er maar één server nodig is en de bestaande SSH-functionaliteit wordt gebruikt.
De integratorworkflow is een gedistribueerd ontwikkelingsmodel waarbij alle gebruikers hun eigen model onderhouden openbaar repository, in aanvulling op hun privé-repository. Het bestaat als een oplossing voor de beveiligings- en schaalbaarheidsproblemen die inherent zijn aan de gecentraliseerde workflow.
Het grootste nadeel van de gecentraliseerde workflow is dat elk ontwikkelaar heeft push-toegang tot het hele project nodig. Dit is prima als je met een klein team van vertrouwde ontwikkelaars werkt, maar stel je een scenario voor waarin je aan een open-bronsoftwareproject werkt en een vreemdeling een bug heeft gevonden, deze heeft gecorrigeerd en de update wil opnemen in de hoofdproject. Je wilt hem waarschijnlijk geen push-toegang geven tot de centrale repository, omdat hij of zij allerlei willekeurige commits zou kunnen pushen en je de controle over het project zou verliezen..
Maar wat u kunt doen is de bijdrager vertellen om de wijzigingen door te drukken zijn of haar openbare repository. Vervolgens kunt u zijn bugfix in uw privérepository opslaan om ervoor te zorgen dat deze geen niet-aangegeven code bevat. Als je zijn bijdragen goedkeurt, hoef je ze alleen maar in een lokale branch samen te voegen en naar de hoofdrepository te pushen zoals gewoonlijk. Je bent een geworden integrator, naast een gewone ontwikkelaar:
In deze workflow heeft elke ontwikkelaar alleen pushtoegang nodig zijn of haar openbare repository. De bijdrager gebruikt SSH om naar zijn of haar openbare repository te duwen, maar de integrator kan de wijzigingen ophalen via HTTP (een alleen-lezen protocol). Dit zorgt voor een veiligere omgeving voor iedereen, zelfs wanneer u meer bijdragers toevoegt:
Merk op dat het team het nog steeds eens moet worden over een enkele "officiële" repository om uit te putten-anders zouden veranderingen on-line worden toegepast en zou iedereen zeer snel uit de pas lopen. In het bovenstaande diagram is "Uw openbare repo" het officiële project.
Als integrator moet u meer afstandsbedieningen bijhouden dan u zou doen in de gecentraliseerde workflow, maar dit geeft u de vrijheid en veiligheid om wijzigingen van elke ontwikkelaar op te nemen zonder de stabiliteit van het project te bedreigen.
Bovendien heeft de workflow van de integrator geen enkel toegangspunt om als knelpunt voor samenwerking te dienen. In gecentraliseerde werkstromen moet iedereen volledig up-to-date zijn voordat wijzigingen worden gepubliceerd, maar dat is niet het geval in gedistribueerde werkstromen. Nogmaals, dit is een direct resultaat van de niet-lineaire ontwikkelstijl die mogelijk is gemaakt door de branch-implementatie van Git.
Dit zijn enorme voordelen voor grote open-sourceprojecten. Het organiseren van honderden ontwikkelaars om aan een enkel project te werken zou niet mogelijk zijn zonder de veiligheid en schaalbaarheid van gedistribueerde samenwerking.
Ondersteuning van deze gecentraliseerde en gedistribueerde samenwerkingsmodellen was alles wat Git ooit had moeten doen. De werkdirectory, de stage, commits, branches en afstandsbedieningen waren allemaal specifiek ontworpen om deze workflows mogelijk te maken, en vrijwel alles in Git draait om deze componenten.
Trouw aan de UNIX-filosofie, werd Git ontworpen als een pakket van interoperabele tools, niet een enkel monolithisch programma. Terwijl je doorgaat met het onderzoeken van Git's talrijke mogelijkheden, zul je zien dat het heel gemakkelijk is om individuele commando's aan te passen aan geheel nieuwe workflows.
Ik laat het nu aan jou over om deze concepten toe te passen op echte projecten, maar als je Git begint te integreren in je dagelijkse workflow, onthoud dan dat het geen wondermiddel is voor projectbeheer. Het is slechts een hulpmiddel voor het bijhouden van uw bestanden, en geen enkele hoeveelheid intieme Git-kennis kan een lukraak set van conventies in een ontwikkelteam goedmaken.
Deze les vertegenwoordigt een hoofdstuk van Git Kortbij, een gratis eBoek van het team van Syncfusion.
