Je bent waarschijnlijk bekend met tools, zoals Git en Subversion. Maar als webontwerpers is het heel goed mogelijk dat, hoewel je zou kunnen zeggen dat je gebruikmaakt van versiebeheer in je projecten, de waarheid is dat je het meestal niet doet. Als u aan deze beschrijving voldoet, hoeft u zich geen zorgen te maken; je bent niet alleen. Sterker nog, het is de volledig onbeantwoorde mening van deze auteur dat de overgrote meerderheid van webontwikkelaars dat niet doen! Het dilemma is dat er een algemene overtuiging is dat versiebeheer strikt is voor hardcore coders, die hun dagen in duisternis doorbrengen, en die zelden komen voor lucht, behalve wanneer de magnetron het doet, wat aangeeft dat de hete zak klaar is om gegeten te worden.
Als u voor het web codeert, of dit nu aan de voorkant of aan de achterkant is, is het uw taak om op verantwoorde wijze te coderen: gebruik versiebeheer.
5 Tekenen dat u te oud bent voor versiebeheer
U hebt geen idee van wat versiebeheer is, of waarom het nuttig zou kunnen zijn.
Je codeert lokaal en hebt geen back-upsysteem.
U maakt een back-up van uw projecten door sporadisch de hoofdmap te dupliceren.
Je hebt per ongeluk een bestand permanent verwijderd en moest helemaal opnieuw beginnen.
Na het maken van een aantal bewerkingen wordt uw toepassing afgebroken en moet u de knop ingedrukt houden Command + Z voor een pijnlijk aantal seconden, terwijl je kijkt hoe de editor je wijzigingen omkeert.
Geef het toe: elke ontwikkelaar heeft zich geïdentificeerd met een van de eerder genoemde tekens op een of ander moment in zijn of haar carrière. Maar onthoud: de eerste stap naar herstel is toegeven dat je een probleem hebt!
5 Onmiddellijke voordelen voor versiebeheer
Per ongeluk die klasse of PSD verwijderd? Voer een enkele opdracht in de terminal uit om terug te keren naar een vorige staat in het project. Ramp vermeden!
Heb je je ooit geamuseerd aangezien je website op de een of andere manier van je bureaublad was verdwenen? Het was daar gisteren, maar vandaag is het weg! Een gratis service, genaamd GitHub, maakt dit een non-issue.
Wie zou in hemelsnaam dit stukje code schrijven dat ik nu uren moet herschrijven? Je hoeft je niet af te vragen wie de schuldige is; Git zal het je vertellen!
Code met verlaten, terwijl je weet dat bij elke commit, "snapshots" van je applicatie worden opgeslagen, voor het geval je op een bepaald moment in de toekomst terug moet naar deze staat.
Accepteer om geen enkele andere reden dat ontwikkelaars die waarschijnlijk veel meer gekruid zijn dan jij, het als een best practice hebben beschouwd. Het is handig om degenen na te bootsen die we bewonderen.
Git?
Git is het meest populaire versiecontrolesysteem dat beschikbaar is.
Dus hoe kan Git meewerken aan dit hele versie besturingselement? Nou, de super nerdy-definitie is dat Git een gedistribueerd versiebesturingssysteem is, ontwikkeld door Linus Torvalds, waarbij elke werkdirectory een eigen repository is met de volledige geschiedenis die op elk moment beschikbaar is. Bovendien biedt Git de mogelijkheid om code te delen en meerdere vertakkingen (of tijdlijnen) voor uw projecten te maken, waardoor het bijzonder geschikt is voor agile ontwikkelteams.
Een begrijpelijker definitie kan zijn: Git is een opdrachtregelprogramma dat u - en andere ontwikkelaars in uw team - gebruikt om frequente snapshots van uw projecten op te slaan. Op elk willekeurig punt biedt het de flexibiliteit om wijzigingen in eerdere staten terug te draaien, met slechts één enkele opdracht.
Het boek van Scott Chacon, 'Pro Git', is in zijn geheel beschikbaar op de Git-website.
Git installeren
Zeker, de eerste stap naar wreckless, "Cowboy Coding" herstel is om Git te downloaden van git-scm.com. Gebruik een van de volgende URL's, afhankelijk van uw besturingssysteem naar keuze.
Mac: http://git-scm.com/download/mac
ramen: http://git-scm.com/download/win
Vervolgens moeten we de installatie net een beetje configureren, door een gebruikersnaam en e-mailadres te koppelen. Open de dichtstbijzijnde console (Terminal op de Mac) en voer het volgende uit:
Maak je geen zorgen; dit hoeft maar één keer te worden getypt, nadat je Git voor het eerst hebt geïnstalleerd. Nu, voor elke actie die je neemt, zal Git deze instellingen gebruiken.
Er zijn verdere configuratieopties, zoals het opgeven welke code-editor moet worden gebruikt, wanneer Git vereist dat je een commit-bericht typt, maar negeer dat voor nu.
Gefeliciteerd, Git is met succes geïnstalleerd!
De basiscyclus
Zoals met elke nieuwe technologie, is er een klein beetje leren vereist.
Een van de moeilijkste aspecten om te leren Git is het ontcijferen waarnaar het verschillende jargon verwijst. Begaat? Staging? Takken? Logs? huh?
Zoals met elke nieuwe technologie, is er een klein beetje leren vereist. Gelukkig, zo complex als Git kan zijn, vooral als webdesigner, zul je merken dat een handvol commando's een lange weg zal gaan. Vergelijk voor vergelijking het Engelse woordenboek en vervolgens het aantal woorden dat we op realistische wijze gebruiken in alledaagse gesprekken. Hetzelfde geldt voor Git - op een veel lager niveau. Dus voel je niet overweldigd. Neem het één opdracht per keer.
Om deze verwarrende terminologie uit te sluiten, is het het beste om eerst te denken in termen van iets tastbaars in de echte wereld: een bestelwagen.
Stel je voor dat je een nieuwe statische website bent begonnen. U hebt mappen gemaakt voor JavaScript- en CSS-bestanden, evenals een index.html-bestand met een beetje standaard HTML. In feite, doe dat nu precies! Als je klaar bent, is het tijd om de eerste commit te maken.
Keer terug naar de Terminal en typ:
git init
Dit commando, "initialize Git", informeert Git dat we versiebeheer voor dit project wensen. Of: "start het contact." Het hoeft slechts één keer te worden uitgevoerd, aan het begin van de levenscyclus van een nieuw project.
Laten we vervolgens bepalen wat de "status" is.
git status
Als u meewerkt, ziet u waarschijnlijk iets in de trant van:
# On branch master # # Initial commit # # Untracked files: # (gebruik "git add ... "opnemen in wat wordt vastgelegd) # # index.html niets toegevoegd om vast te leggen maar niet-gevonden bestanden aanwezig (gebruik" git add "om te volgen)
Hoewel enigszins verwarrend, als we een moment nemen, zullen we zien dat we standaard werken aan een 'branch', genaamd 'master'. Vervolgens hebben we één niet-gevonden bestand: index.html. Hieruit kunnen we ontcijferen dat Git niet magisch is; het moet worden verteld welke bestanden in de gaten moeten worden gehouden, om zo te zeggen.
Benieuwd waarom de JavaScript- en CSS-directory's niet zijn opgenomen in de lijst met niet-gevonden bestanden? Git volgt bestanden, geen mappen. Een veel gebruikte techniek om lege mappen in een commit op te nemen, is om een .gitignore-bestand aan elke submap toe te voegen. Daarover later meer!
Bestanden volgen
Om bestanden bij te houden, moeten we ze eerst toevoegen aan het verzamelgebied - of ze in de vrachtwagen zetten.
git add index.html
Als we de status opnieuw controleren, zien we nu:
Op branchmaster # # Initiële commit # # Aan te passen wijzigingen: # (gebruik "git rm --cached ... "unstage) # # nieuw bestand: index.html
Uitstekend; Git bekijkt dit bestand op wijzigingen. In dit geval hebben we slechts één bestand toegevoegd. Als we liever alle bestanden aan het verzamelgebied toevoegen, kunnen we het periodesymbool gebruiken.
git add .
Houd er rekening mee dat de truck nog niet is vertrokken; we hebben slechts een paar dozen (of bestanden) achterin geladen. Om de momentopname uit te voeren en een kopie van het project op te slaan in de huidige getraceerde status, moet een commit worden uitgevoerd.
git commit -m 'Eerste commit'
Hierboven hebben we een nieuwe commit gemaakt en een bericht van 'First commit' gegeven. Daarmee is onze eerste commit voltooid en is de truck naar de fabriek vertrokken, met een kopie van het project achterin.
Gebruik een nieuwe opdracht om uw werk te verifiëren: "log."
git log commit 02c934fcaf3de7677273b74d8ad3ed5041066986 Auteur: Jeffrey Way Datum: wo 19 december 15:07:23 2012 -0500 Eerst verbinden
Perfect, er is een nieuwe commit gecreëerd en het lijkt erop dat de commit een uniek referentie-ID heeft. Vijl dat voor nu weg.
Als u nogmaals de status controleert.
git status
Omdat er sinds de laatste commit geen wijzigingen zijn aangebracht, vertelt Git ons zoveel:
# Op branchemaster niets om te plegen (werkmap schoon)
Succes! 90% van je Git-gebruik zal deze cyclus volgen.
Veranderingen maken
Voeg bestanden toe aan het verzamelgebied
Voer een commit uit met een bericht dat de actie beschrijft die plaatsvond
Spoel en herhaal!
Laten we doorgaan naar de volgende stap. Als eenvoudig voorbeeld willen we misschien een eenvoudig reset-stylesheet opnemen in ons project. We zullen de meest elementaire (misschien slecht geadviseerde) resets schrijven.
/ * css / reset.css * / * marge: 0; opvulling: 0;
Ga nu terug naar index.html en voeg een verwijzing naar dit bestand toe:
Als vuistregel: als je de persoon die naast je zit, kunt beschrijven welke verandering je net in een project hebt aangebracht, dan verdient het waarschijnlijk een commit. Commit vaak. Laten we dat nu doen; terug naar de terminal!
git add. git commit -m 'Toevoegen en opnemen reset stylesheet.'
Bij het schrijven van commit-berichten, wordt dit over het algemeen als de beste praktijk beschouwd om in de onvoltooid tegenwoordige tijd te schrijven. Dus "voeg bestand toe" in plaats van "toegevoegd bestand".
Snel vooruit naar morgen, en nu vertelt je baas je dat ze je eenvoudige resetbestand niet willen gebruiken. In plaats daarvan zouden ze liever het populaire Normalize-stylesheet gebruiken, door Nicolas Gallagher.
Geen probleem; met Git is dit een gemakkelijke oplossing. Laten we de vorige commit terugdraaien en de nodige wijzigingen aanbrengen.
git zet HEAD terug
Met Git luidt de regel: "herschrijf nooit de geschiedenis".
Met deze opdracht worden alle wijzigingen die u in de meest recente commit hebt aangebracht, ongedaan gemaakt. In wezen is het een commit die precies het tegenovergestelde doet van wat de vorige deed. Waarom terugkeren, in plaats van de commit volledig ongedaan te maken? Nogmaals, omdat we de beste werkwijzen volgen. Met Git luidt de regel: "herschrijf nooit de geschiedenis". De wijzigingen terugdraaien, maar nooit wissen en ongedaan maken.
Als je op Enter raakt, wordt je met de tekst naar een nieuw scherm gebracht, "Revert" Toevoegen en opnemen van het reset-stylesheet. " Op dit punt bevindt u zich in de Vi-modus (hoewel u vrij bent om Git te configureren voor het gebruik van elke code-editor die u maar wilt). Voorlopig gaat u met de standaardinstellingen, slaat u op en sluit u af. Voltooi dit door te typen: wq (Write and Quit).
En met dat enkele commando zijn de wijzigingen ongedaan gemaakt. Ga je gang en controleer het om het zeker te weten. Het bestand style.css is verwijderd en er is geen verwijzing meer naar het stijlblad binnen index.html. Dit is de kracht van Git! Omdat we een ontwikkelstijl hebben aangenomen waarbij we vaak vastleggen, wanneer deze in situaties wordt geplaatst, waar bewerkingen moeten worden teruggedraaid, is slechts één opdracht vereist. Nooit meer drukken Command-Z voor de eeuwigheid!
Na het verzoek van de baas, laten we het project bijwerken om Normalize.css te gebruiken, dat we hebben gedownload en geplaatst in css / normalize.css.
Binnen index.html, verwijs het:
En tenslotte verbinden we de veranderingen.
git add. git commit -m "Include Normalize in project"
Hoewel dit zeker een eenvoudig voorbeeld was, stel je dan voor hoe nuttig deze techniek kan zijn voor grotere veranderingen, die meerdere bestanden in je applicatie omvatten. Door alle gerelateerde wijzigingen in één commit te groeperen, bereiken we maximale flexibiliteit en veiligheid.
Ruimte om te experimenteren
Ooit op een punt in een project gestaan, wanneer je wilt experimenteren met een idee dat de voltooide applicatie wel of niet haalt? Hoewel het klopt dat je de commit altijd kunt terugdraaien als de zaken niet volgens plan verlopen, is het een slimmer idee om, om verschillende redenen, vertakking te gebruiken..
De beste manier om het concept van Git-vestigingen te illustreren, is door te verwijzen naar Terug naar de toekomst 2.
Als je een nerdy-ontwikkelaar bent en de trilogie Back to the Future niet hebt bekeken, stop dan met wat je doet en bekijk ze!
Ga verder, onthoud het deel in Terug naar de toekomst 2, nadat Marty en Doc terug zijn uit 1985 in de toekomst, maar ontdekken dat alles anders is? Bij een ontmoeting in Doc's, nu vernietigde labo, tekent Doc een diagram, waarin wordt beschreven hoe, op een gegeven moment, "de tijdlijn zich naar deze raaklijn vertrok en een alternatief 1985 creëerde." Dit is net als een vertakking!
Overweeg ons huidige demoproject; er is nu één tijdlijn: een rechte lijn. Zodra we een filiaal creëren om aan ons idee te werken, breken we af van deze tijdlijn en maken we er een nieuwe. Op dit punt bestaan beide tijdlijnen en kunnen ze hun eigen respectieve commits bevatten, zonder zich met elkaar te bemoeien.
Hoe is dit nuttig? Overweeg een flexibele ontwikkelingscyclus - een cyclus waarbij u of uw team meerdere keren per week updates implementeert. Als je vasthoudt aan de "single timeline" -benadering, zou het implementeren van bijvoorbeeld een eenvoudige typefix niet mogelijk zijn totdat je ook aan je idee hebt gewerkt. Met vertakking hebben we echter de flexibiliteit om zo lang te nemen als we nodig hebben voor ons idee, terwijl we toch de hoofdtak (de standaard en primaire) vrijmaken voor het implementeren van de typofix.
Ga als volgt te werk om een nieuw filiaal te maken:
$ git branch idea $ git checkout idee
Of combineer deze twee commando's tot één.
git checkout -b idee
Dit vertaalt zich naar: maak een nieuwe tak, genaamd "idee" (vervang dit om meer beschrijvend te zijn van waar je aan werkt, natuurlijk), en schakel er naar over.
Vanaf dit punt wordt er binnen de mastertak geen rekening gehouden met eventuele wijzigingen en commits die u aanbrengt. Ga je gang, probeer het eens. Bewerk index.html en breng een kleine wijziging aan:
We hebben nu onze eerste commit gemaakt in deze nieuwe tijdlijn. Ons fictieve idee heeft nog steeds werk nodig, maar we zijn onderweg! Maar nu heeft een klant zojuist een typfout gemeld die we zo snel mogelijk moeten oplossen. Omdat we takken correct gebruiken, kunnen we terugkeren naar de hoofdtak, de typfout corrigeren en implementeren.
Zodra onze ideeënfunctie is voltooid, wordt het tijd om deze opnieuw samen te voegen in de hoofdtak.
git checkout master git idee samenvoegen
Als alles volgens plan verloopt, wordt je featuretak met succes opnieuw samengevoegd in de hoofdtak, waardoor de alternatieve tweede tijdlijn uit 1985 wordt opgelost!
Dat gezegd hebbende, zul je ongetwijfeld situaties tegenkomen, wanneer Git zijn voeten schijnbaar met de grond in de grond plant en weigert door te gaan zoals gevraagd. In deze gevallen is Git geen ruk zonder reden! Hoogstwaarschijnlijk heeft het probleem betrekking op een conflict dat eerst moet worden opgelost voordat Git kan doorgaan. Stel je voor dat je probeert een bestand terug te voegen in de hoofdtak; het enige probleem is dat, sinds de vertakking is gemaakt, het bestand is bewerkt in zowel de functietak, als de master. In situaties zoals deze, hoe zou Git mogelijk weten welke versie van het bestand voorrang zou moeten krijgen bij het samenvoegen van de twee? Dat doet het niet, en dit is wat we een conflict noemen.
Index.html automatisch samenvoegen CONFLICT (inhoud): conflict samenvoegen in index.html Automatisch samenvoegen mislukt; repareer conflicten en voer vervolgens het resultaat uit.
Voordat Git kan doorgaan, moet je het conflict oplossen door index.html te bewerken.
Bestanden negeren
Er zal waarschijnlijk een punt komen, wanneer u besluit dat het het beste is om bepaalde bestandstypen niet met Git te volgen. Voorbeelden hiervan zijn de algemene .DS_STORE (waarmee Mac-gebruikers vertrouwd zijn), mappen bouwen en tijdelijk gecompileerde assets.
Git, via een .gitignore-bestand, laat ons toe om bepaalde bestandstypes te negeren. Om hiervan gebruik te maken, maakt u een nieuw .gitignore-bestand in de root (maar niet beperkt tot) van uw project. Geef daarin een lijst met bestanden of bestandstypen op die moeten worden genegeerd. Hier is een eenvoudig voorbeeld:
.DS_STORE build / * .log * .sql * .exe
Sociale codering
GitHub maakt sociale codering mogelijk.
Tot nu toe heb je geleerd hoe je je code lokaal vastlegt. Maar hoe kunnen deze wijzigingen worden gedeeld met uw team of met de rest van de wereld? Ga naar GitHub.
Met GitHub kun je je code delen met de wereld. Het is de grootste open source community die er is.
Zodra u zich aanmeldt voor een nieuw account op github.com, moet u een paar stappen volgen om een speciale sleutel te genereren, om uw computer te koppelen aan uw GitHub-account. Maak je geen zorgen; als u de stappen volgt, zou u geen problemen moeten hebben.
Op dit punt kunnen we een nieuwe repository maken en ons kleine project pushen om het met de wereld te delen. Nadat u bent ingelogd, klikt u op de knop "Nieuwe repository", geeft u uw repo een naam en klikt u op "Repository maken". Vervolgens krijg je een aantal opdrachten te zien die in de terminal kunnen worden geplakt. Omdat we al een bestaande repo hebben, hebben we de tweede optie nodig:
Dit instrueert Git om onze nieuwe externe repository toe te voegen en alias als "oorsprong". Vervolgens duwen we de hoofdtak (niet het idee één) naar de afstandsbediening met het alias 'oorsprong'.
Dat is het! Keer terug naar de browser, vernieuw de pagina en je zult je nieuwe nieuwe repository vinden, wachtend om te worden gedeeld met de rest van de wereld.
Wanneer andere leden van uw team de wijzigingen willen aanbrengen die u hebt aangebracht, hoeven ze alleen het volgende uit te voeren:
git pull
Deze opdracht haalt de laatste updates binnen die naar GitHub zijn geduwd! Naast het delen van code biedt GitHub ook de mogelijkheid om populaire open source-projecten bij te houden en eraan bij te dragen, evenals een probleemoplosser voor bugs en functieverzoeken. Het is sociale codering op zijn best!
Gedachten sluiten
Hoewel we slechts het oppervlak hebben geschetst van wat Git kan, is de waarheid dat, nogmaals, voor 80% van je Git-gebruik, de technieken waarnaar in dit artikel wordt verwezen, zullen volstaan. Maak een functietak, schrijf wat code, voeg het toe aan het verzamelgebied en maak het vast met een bericht. Wanneer je klaar bent, voeg je het opnieuw in de hoofdtak en implementeer je! Vervolgens afspoelen en herhalen!
Vergeet niet: StackOverflow is je beste vriend wanneer je gestompt bent. Wat het probleem ook is, anderen zijn in exact dezelfde situatie geweest. Zoek daar eerst.
Share
Accentsconagua
