Externe opslagplaatsen met Git

Behandeling Git Als hulpmiddel voor samenwerking is het een noodzaak geworden in de huidige tijd, waar de meeste ontwikkelingen het gebruiken om veranderingen verenigd en zonder conflicten te houden.
In eerdere tutorials hebben we geleerd hoe we repositories in lokale omgevingen kunnen beheren en dit is niet slecht als we leren hoe we GitIn de wereld van het werk wordt het echter anders behandeld en meestal zullen we moeten werken aan een externe repository, die meerdere vertakkingen zal hebben en elke aanwezige ontwikkelaar voortdurend wijzigingen uploadt.
Een externe repository is er een die niet van ons is, die zich op een cloudserver, op de computer van een andere ontwikkelaar of zelfs op een bestandssysteem kan bevinden. De belangrijkste functie van deze repositories is dat andere ontwikkelaars ermee kunnen samenwerken, inclusief wij via de branches of takken.
Er zijn veel services waarmee we onze externe repository kunnen maken, we hebben: GitHub maar dit is gericht op persoonlijke projecten en samenwerkingen tussen de ontwikkelaarsgemeenschap met bepaalde projecten en we hebben Bitbucket, die is gericht op particuliere projecten en werkteams in bedrijven of organisaties.
Voor deze tutorial zullen we gebruiken Bitbucket, is gratis en komt het meest overeen met de werkfilosofie waarop we ons willen richten.
We hebben vermeld dat een externe repository niet van ons is, omdat deze zich op een platform bevindt dat niet van ons is, maar we kunnen er bewerkingen op uitvoeren, variërend van het maken ervan tot het verwijderen als we dat willen.
Om onze externe repository te maken, gaan we naar de pagina Bitbucket en als we niet zijn geregistreerd, maken we ons account aan, gaan naar binnen en in ons hoofdpaneel zoeken we naar de optie Creëren om de externe repository te maken.

We noemen onze repository, nemen een beschrijving op, selecteren de zichtbaarheid en het vermogen om te presteren vorken, waar we bovendien de taal kunnen selecteren waarin ons project zal worden gebaseerd, drukken we tenslotte op maken en we zullen onze externe repository laten maken.
We gaan ervan uit dat we helemaal opnieuw beginnen en dat we geen project hebben, maar dat we binnenkort onze wijzigingen gaan uploaden, hiervoor moeten we de map maken waar het project zal zijn en de eerste duw.
Om dit te doen, maken we een map en daarin openen we een opdrachtconsole en initialiseren we deze als een repository gitHierna gaan we de verbinding maken met onze externe repository, die we kunnen vinden in het hoofdpaneel van onze nieuw gecreëerde repository:

Nu moeten we onze eerste uitvoeren duw Om te controleren of alles correct werkt, zullen we een nieuw bestand maken, dat een .txt-bestand kan zijn met een eenvoudige tekst. We gebruiken het commando toevoegen om het aan de repository toe te voegen, voegen we onze eerste verbinden en tot slot doen we de duw naar het filiaal meester:

Zoals we zien verliep alles soepel, maar voor gebruikers die beginnen en zich een beetje onzeker voelen over de tool, en zich afvragen of de bestanden zijn geüpload, kunnen ze naar Bitbucket en ververs de repository en je kunt de gemaakte wijzigingen zien:

VERGROTEN

Bitbucket is uiterst nuttig, het stelt ons niet alleen in staat om repositories te creëren, maar de webtoepassing stelt ons in staat om gegevens te zien zoals de branch in de repository, de vorken die zijn gedaan, de activiteit erin en zelfs uitnodigingen naar andere ontwikkelaars sturen.
Zodra we onze repository hebben gemaakt, is het tijd om het samenwerkingswerk te starten, hiervoor moeten we eerst de branches of takken. Afgezien van de tak meester We moeten een extra branch maken voor het project in het algemeen en dit is degene waarin de ontwikkelaars zullen doen samenvoegen en upload uw laatste wijzigingen.
Individuele takkenBovendien wordt aanbevolen dat elke ontwikkelaar er een vertakking voor heeft, zodat de wijzigingen van elk teamlid in secties worden verdeeld en in het geval dat er een fout is in de uiteindelijke upload, kunnen ze zonder veel problemen worden geretourneerd.
We zullen de tak maken met de naam ontwikkelen en een persoonlijke branch voor onze wijzigingen, we doen dit met het commando tak gevolgd door de naam van de tak, laten we eens kijken hoe het eruit ziet in onze console:

Hiermee worden onze vestigingen lokaal gemaakt, maar totdat we er wijzigingen in aanbrengen en de duw ze worden niet geregistreerd in onze repository, hiervoor gaan we naar onze persoonlijke branch met het commando uitchecken en we verifiëren met toestand dat we niets te doen hebben verbinden, dit zou zo moeten zijn omdat het een nieuwe branch is, laten we eens kijken:

Nu gaan we mappen en enkele bestanden maken om gewicht te geven aan ons project, maar laten we niet vergeten dat de wijzigingen in onze branch zullen zijn. Na het uitvoeren van deze bewerkingen moeten we ze toevoegen met toevoegen, voer de . uit verbinden corresponderend en tot slot de duw naar onze branch, laten we deze bewerkingen eens bekijken in onze opdrachtconsole:

We hebben de upload naar onze branch al gemaakt, nu hoeven we alleen hetzelfde te doen met de development branch, maar hiervoor hoeven we het add of commit commando niet te gebruiken, hiervoor gebruiken we het commando samenvoegen Om de wijzigingen aan te sluiten die niet aanwezig zijn in de branch, bespaart dit ons veel werk en stelt ons in staat om de acties die we uitvoeren op de repository bij te houden.
Om dit te doen, moeten we naar de ontwikkelingstak gaan met het commando uitchecken en daar gaan we het commando uitvoeren samenvoegen wijzend naar de jacosta-tak om deel te nemen aan de wijzigingen die we hebben aangebracht.

Met deze actie wordt de update uitgevoerd, maar dit betekent niet dat we de wijzigingen naar de vertakking hebben geüpload op dezelfde manier als we de duw, maar dit bespaart ons wat extra stappen en geeft ons een schoner uploadproces. Deze actie zal de nieuwe branch maken en onze wijzigingen verenigen, als we nog steeds niet vertrouwen op wat de console ons informeert waar we naartoe kunnen gaan Bitbucket, waar we de nieuwe filialen kunnen zien die zijn gemaakt, evenals de acties die we hebben uitgevoerd onder de sectie recente activiteit:

VERGROTEN

Zoals we kunnen zien, hebben we zowel de nieuwe vestigingen als de nieuwe wijzigingen die zijn aangebracht. Het is belangrijk om te vermelden dat dit de normale workflow is die we moeten uitvoeren wanneer we in collaboratieve omgevingen werken, anders zouden we conflicten veroorzaken, waardoor ons team zelfs een paar uur zou besteden aan het oplossen van problemen met de repository.
Wat we zojuist hebben gezien, maakt deel uit van het idee dat wij degenen waren die de externe repository hebben gemaakt, maar op het moment dat we worden uitgenodigd voor een van hen, verandert het proces een beetje. Laten we aannemen dat ons team ook gebruik maakt van Bitbucket en ze creëerden de repository op het platform, we gingen naar het hoofdpaneel, we vonden de optie Kloon en wanneer we erop drukken, zien we de exacte regel om deze actie uit te voeren die ons precies kloont wat zich op dat moment in de repository bevindt:

VERGROTEN

We hebben vermeld dat deze actie kloont of kopieert wat zich op dat moment precies in de repository bevindt, maar het kan zijn dat sommige ontwikkelaars een last-minute wijziging uploaden en deze niet is opgenomen in de kloon, dus het zal niet in de kopie staan die we in onze machine zullen hebben.
Veel voorkomende foutDeze fout is een van de meest voorkomende en waarbij veel beginnende gebruikers repositories niet kunnen beheren met Git, en het is het uploaden van bestanden naar de repository zonder eerst te controleren of er wijzigingen zijn aangebracht. Maar de oplossing is eenvoudig, wat misschien wel het meest gecompliceerde is, is om de oefening over te nemen en de opdracht uit te voeren trekken voordat u aan het project begint en voordat u iets uploadt, voorkomt dit de gênante situatie van een door ons veroorzaakt repository-conflict.
Ten slotte is het belangrijk om te vermelden dat, hoewel Git stelt ons in staat om de controle over ons project en onze bestanden te behouden en de wijzigingen in het ontwikkelingsteam te verenigen, het is geen hulpmiddel dat we alleen voor projectbeheer kunnen gebruiken.
We raden aan om het hand in hand te nemen met toepassingen zoals asana of Trello, om ervoor te zorgen dat onze projecten op alle fronten worden gedekt, op deze manier weten we dat ze altijd de laatste wijzigingen zullen hebben en ook dat de data en verplichtingen die ervoor zijn vastgesteld, zijn wordt zonder mankeren ontmoet. .
Hiermee beëindigen we deze tutorial waar we onze externe repository kunnen maken met Bitbucket en bovendien konden we alle benodigde workflows zien om er optimaal mee om te gaan wanneer we in een collaboratieve ontwikkelomgeving werken.Vond je deze Tutorial leuk en heb je eraan geholpen?Je kunt de auteur belonen door op deze knop te drukken om hem een ​​positief punt te geven