Inleiding tot het GIT-versiebeheersysteem

Git is een van de meest voorkomende term die programmeurs de afgelopen vier tot vijf jaar hebben gehoord. Ik zal hier wat inzicht geven in deze tool en waarom het zo populair is onder de programmeurs. In dit onderwerp gaan we meer te weten over het GIT-versiebeheersysteem.

Wat is en waarom versie Controller?

Linus Torvalds die de Linux-kernel is gestart, is de persoon die deze software heeft gemaakt om verschillende versies van broncode bij de programmeurs te onderhouden en te volgen.

Scenario 1

Stel je een team van vijf leden voor dat werkt aan masterbroncode die verschillende functies verbetert. Bedenk eens hoe ze kunnen werken aan dezelfde broncode zonder verwarring over elkaars veranderingen? Iedereen moet weten wat anderen vier doen en er mag geen sprake zijn van nalatigheid. En tegen het einde van het werkuur moeten ze wat tijd besteden aan het coördineren van elkaars werken zodat uiteindelijk één broncode behouden blijft. Het ziet er veel hectisch uit en absoluut handmatig ingrijpen bij het onderhouden van de broncode is riskanter. Dus om te helpen of te zeggen om al deze versies te automatiseren waaraan alle vijf programmeurs werken, hebben we een correct geschreven versiecontroller nodig en GIT is er een van. Er is een term voor de bovenstaande stappen en deze wordt Source Code Management of Software Configuration Management (SCM) genoemd.

Scenario # 2

Overweeg nu nog een scenario waarin automatisering van versiecontrollers helpt. We hebben de eerste codeversie geschreven en de klant heeft goedgekeurd om deze in productie te installeren, laat dit versie 1.0 zijn. Nu biedt de klant na een paar maanden een verbeteringswerk en werkt u aan eerder geschreven om versie 1.1 te ontwikkelen en aan de klant voor te leggen. Maar de cliënt suggereert een andere aanpak en deze versie 1.1 is niet nuttig voor u volgens de nieuwe benadering van de cliënt. Dus je gooit dit weg en werkt aan versie 1.2 die wordt ingediend en goedgekeurd. En zo blijf je werken aan het ontwikkelen van verschillende versies. Maar vind je niet dat het handmatig opslaan van alle versies ergens en het onderhouden van de broncode geen rommel is? Op een gegeven moment moet je misschien versie 1.1 raadplegen die je hebt weggegooid en die niet handig is.

Dus om verschillende versies van code te behouden die zijn geschreven door een of meerdere programmeurs, gebruiken we versiecontrollers.

Verschillende soorten versiecontroller

Er zijn verschillende soorten tools beschikbaar en hieronder vindt u er enkele

  1. Subversion - Sinds ontwikkeld door Apache, veel gebruikt door Apache-leveranciers.
  2. Git
  3. Bazaar
  4. kwikmiddel

In principe zijn er twee soorten methoden voor versiebeheersysteem waarop de bovengenoemde tools werken. Zij zijn

Gecentraliseerd versiebeheersysteem (CVCS) Gedistribueerd versiebeheersysteem (DVCS)

1. CVCS

Hier wordt de geschreven code opgeslagen in de gecentraliseerde repository of op de gecentraliseerde server. Geen werkkopie beschikbaar op lokale machines, wat een enorm nadeel is als er een serverstoring is. Ik moet een actieve serververbinding hebben om altijd aan de repo te werken. SVN gebruikt dit besturingssysteem

2. DVCS

Ook hier hebben we de broncode op de server, maar daarnaast hebben we deze als lokale kopie op werkende machines. Dus zelfs als er een storing op serverniveau is, kunnen we de lokale werkkopie naar de server spiegelen wanneer deze wordt hersteld. Deze beschikbaarheid van een lokaal werkkopie op elke machine die verantwoordelijk is voor de term 'Dsistriibuted' in DVCS. Git, Mercurial maakt gebruik van een gedistribueerd versiebeheersysteem

Git gebruikt het concept van vertakking of meer technisch genoemd als Trunk Based Development TBD. Wat het eigenlijk betekent, is dat we vanuit de master meerdere branches kunnen maken en op deze branches kunnen programmeurs werken en hun wijzigingen in deze branches vastleggen en elk van deze commits wordt bijgehouden. En zodra klanten het goedkeuren, kunnen we alle filialen samenvoegen tot de mastercode in de productie. Op deze manier heeft dit geen directe invloed op de masterbroncode. Direct aan master-broncode werken is riskanter en moet worden vermeden. We kunnen werken aan filialen en verschillende testscenario's uitvoeren en zodra de definitieve versie is gestabiliseerd en goedgekeurd, kunnen we eraan werken om de master samen te voegen, wat het risico met een aanzienlijk bedrag vermindert.

Git is eigenlijk gratis en voor Mac-gebruikers is het standaard beschikbaar. In Linux kunnen we git installeren en voor Windows hebben we iets, Git Bash. Er zijn twee meest populaire repositorybronnen waar we met Git kunnen werken en ze zijn Git Hub en Bit Bucket en organisaties die ervoor kiezen om zich op hun voorkeur te baseren.

Voordelen van het GIT-versiebeheersysteem

  • Ondersteunt zowel oudere vorm van ontwikkeling die een lineaire ook niet-lineaire vorm van ontwikkeling is
  • Sinds de distributie in de natuur, minder zorgen over single point-serverstoringen. We kunnen de code van de lokale repo altijd spiegelen naar de server.
  • We kunnen ook een beveiligingslaag bovenop git implementeren die toegangsbeperkingen kan toewijzen in commit pull en push.
  • Werkt op meerdere platforms zoals Mac, Linux, Windows, enz
  • Absoluut gratis en open-source
  • Efficiënt en snel vanwege de gedistribueerde natuur
  • Duidelijke tracking van commits, updates, keert terug, versies, push en pulls
  • Biedt GitBash voor vensters die gemakkelijk te gebruiken zijn.
  • Er zijn ook verschillende GUI beschikbaar om bovenop GIT te werken
  • Het vereist niet altijd een actieve netwerkverbinding, aangezien de lokale repository beschikbaar is.

Werken met Git

  • Maak de werkende tak van bronmaster of van een andere tak, afhankelijk van de vereiste
  • Kloon de branch op lokaal met GitBash voor Windows
  • Werk aan de branche en voer wijzigingen of toevoeging van componenten uit
  • Leg de wijzigingen vast en verwijs commit tracker
  • Als je denkt dat commit onnodig was, kun je de commit terugzetten naar de eerdere
  • Als meerdere programmeurs dan aan dezelfde branch werken, moet de lokale repo worden bijgewerkt voordat uw wijzigingen worden doorgevoerd. Dus voer PULL uit
  • Nu kunt u de PUSH uitvoeren
  • Nadat beoordeling en codegoedkeuring bij uw filiaal hebben plaatsgevonden, kunnen we de code naar productie verplaatsen, op een willekeurige manier of op een manier die de organisatie gebruikt.
  • Voeg de vertakking samen met de master zodat we de code erin hebben bijgewerkt.

Git is het meest gebruikte gedistribueerde versiebeheersysteem vanwege zijn gedistribueerde aard, geen enkel storingspunt en is open source. Je kunt proberen ermee te werken met behulp van voorbeeldcode in GitHub en GitBash in Windows-pc omdat git-opdrachten eenvoudig en gemakkelijk online beschikbaar zijn.

Aanbevolen artikelen

Dit is een handleiding voor het GIT-versiebeheersysteem. Hier bespreken we de verschillende typen versiecontrollers met voordelen en werking. U kunt ook het volgende artikel bekijken voor meer informatie-

  1. GIT-opdrachten
  2. Inleiding tot GIT
  3. Git Alternatieven
  4. Wat is Git?
  5. Versies van het tableau
  6. Git Origin Master
  7. Wat is Hub?
  8. Drie fasen van Git-levenscyclus met de workflow
  9. Hoe GIT Cherry-pick met Voorbeeld te gebruiken?

Categorie: