Du er sannsynligvis kjent med verktøy, som Git og Subversion. Men som webdesignere er det ganske mulig at, selv om du kanskje sier at du utnytter versjonskontroll i prosjektene dine, er sannheten at du oftere ikke gjør det ikke. Hvis du passer denne beskrivelsen, ikke bekymre deg; du er ikke alene. Faktisk er det denne forfatterens helt uoppdagede oppfatning at det store flertallet av webdesigneren ikke gjør det! Utfordringen er at det er en felles tro på at versjonskontrollen er strengt for hardcore-kodere, som tilbringer sine dager i mørket, og som sjelden kommer opp for luft, bortsett fra når mikrobølgeovnen signalerer at hetlommen er klar til å bli spist.
I virkeligheten, hvis du kodes for nettet, enten på forsiden eller baksiden, er det din plikt å kode på ansvarlig måte: bruk versjonskontroll.
5 tegn som du er forsinket for versjonskontroll
Du har ikke noe konsept om hvilken versjonskontroll som er, eller hvorfor det kan være nyttig.
Du kodes lokalt, og har ikke noe backup system.
Du sikkerhetskopierer prosjektene dine ved sporadisk duplisering av rotkatalogen.
Du slettet ved et uhell en fil permanent, og måtte rekondere fra bunnen av.
Ved å gjøre en rekke endringer, bryter søknaden din, hvor du må holde nede Kommando + Z i et smertefullt antall sekunder, mens du ser på redaktøren omvendt endringene dine.
Innrøm det: hver utvikler har identifisert med et av de tegnene som er nevnt tidligere på et eller annet tidspunkt i karrieren sin. Men husk: Det første trinnet for utvinning er å innrømme at du har et problem!
5 Umiddelbare fordeler til versjonskontroll
Uhell slettet den klassen eller PSD? Kjør en enkelt kommando i terminalen for å gå tilbake til en tidligere tilstand i prosjektet. Katastrofe unngått!
Noen gang gledet seg i horror, siden nettstedet ditt på en eller annen måte forsvant fra skrivebordet ditt? Det var der i går, men i dag er det borte! En gratis tjeneste, kalt GitHub, gjør dette til et ikke-problem.
Hvem pokker ville skrive denne koden som jeg nå må tilbringe timer omskriving? Du trenger ikke å lure på hvem som skal klandre; Git vil fortelle deg!
Kode med oppgivelse, mens du vet at, med hver forpliktelse, blir "øyeblikksbilder" av din søknad lagret, bare hvis du trenger å rulle tilbake til denne staten på et tidspunkt i fremtiden.
Hvis ingen annen grunn godtar at utviklere som sannsynligvis er mye mer erfarne enn du har sett det som en god praksis. Det er nyttig å etterligne de som vi beundrer.
Git?
Git er det mest populære versjonskontrollsystemet tilgjengelig.
Så hvordan går Git-faktor inn i hele versjonens kontrollting? Vel, den supernerdige definisjonen er at Git er et distribuert versjonskontrollsystem, utviklet av Linus Torvalds, hvor hver arbeidsregister er sitt eget lager med hele historien tilgjengelig når som helst. I tillegg tilbyr Git muligheten til å dele kode, og opprette flere grener (eller tidslinjer) for dine prosjekter, noe som gjør den spesielt egnet for smidige utviklingsgrupper.
En mer forståelig definisjon kan være: Git er et kommandolinjeverktøy som du - og andre utviklere på laget ditt - bruker til å lagre vanlige øyeblikksbilder av prosjektene dine. På et gitt punkt gir det fleksibilitet til å rulle tilbake endringer i tidligere stater, med bare en enkelt kommando.
Scott Chacons bok, 'Pro Git', er tilgjengelig i sin helhet på Git nettsiden.
Installere Git
Sikkert, det første skrittet for å ødelegge, "Cowboy Coding" -gjenoppretting er å laste ned Git fra git-scm.com. Bruk en av følgende nettadresser, avhengig av hvilket OS du har valgt.
Mac: http://git-scm.com/download/mac
Windows: http://git-scm.com/download/win
Deretter må vi konfigurere installasjonen bare ved å knytte et brukernavn og en e-postadresse. Åpne din nærmeste konsoll (Terminal på Mac), og kjør:
Ikke bekymre deg; dette må bare skrives en gang etter at du først installerer Git. Nå, for alle handlinger du tar, bruker Git disse innstillingene.
Det er flere konfigurasjonsalternativer, for eksempel å angi hvilken koderedigerer som skal brukes, når Git krever at du skriver inn en commit-melding, men ignorer det for nå.
Gratulerer, Git er installert!
Grunnleggende syklus
Som med ny teknologi, er det en liten del av læring som kreves.
Et av de vanskeligste aspektene ved å lære Git er å dechiffrere hva de forskjellige jargongene refererer til. Begår? Staging? Grener? Logger? Hu h?
Som med ny teknologi, er det en liten del av læring som kreves. Heldigvis, så komplisert som Git kan være, spesielt som en webdesigner, vil du oppdage at en håndfull kommandoer vil gå langt. Til sammenligning kan du vurdere engelsk ordbok, og deretter antall ord som vi realistisk bruker i hverdagssamtaler. Det samme gjelder for Git - på et mye lavere nivå. Så føl deg ikke overveldet. Ta det en kommando av gangen.
For å slå ut denne forvirrende terminologien, er det best å først tenke på noe konkret i den virkelige verden: en leveringsbil.
Tenk deg at du har begynt en ny statisk nettside. Du har opprettet mapper for JavaScript- og CSS-filer, samt en index.html-fil med en bit av boilerplate HTML. Faktisk gjør det så mye akkurat nå! Når du er ferdig, er det på tide å lage den første plikten.
Gå tilbake til Terminal, og skriv:
git init
Denne kommandoen, "initialiser Git," informerer Git at vi ønsker versjonskontroll for dette prosjektet. Eller, "start tenningen." Den må bare utføres en gang, i begynnelsen av et nytt prosjekts livssyklus.
Neste, la oss bestemme hva "status" er.
git status
Hvis du jobber sammen, ser du sannsynligvis noe i tråd med:
# På grenmester # # Foreløpig commit # # Untracked files: # (bruk "git add ... "for å inkludere i det som vil bli forpliktet) # # index.html ingenting lagt til for å begå, men uopptatte filer tilstede (bruk" git add "for å spore)
Selv om det er litt forvirrende, ser vi at vi som standard jobber med en "gren", som kalles "master". Deretter har vi en usporret fil: index.html. Fra dette kan vi tyde på at Git ikke er magisk; Det må bli fortalt hvilke filer å holde øye med, så å si.
Nysgjerrig hvorfor JavaScript og CSS kataloger ikke er inkludert i listen over ikke sporede filer? Git spor filer, ikke mapper. En vanlig teknikk, for å inkludere tomme kataloger i en forpliktelse, er å legge til en .gitignore-fil til hver underkatalog. Mer om det senere!
Sporing av filer
For å spore filer må vi først legge dem til stasjonsområdet - eller sette dem på trucken.
git legg til index.html
Nå, hvis vi sjekker statusen igjen, ser vi:
På grenmester # # Foreløpig commit # # Endringer som skal forpliktes: # (bruk "git rm - cached ... "til unstage) # # ny fil: index.html
Utmerket; Git ser på denne filen for endringer. I dette tilfellet har vi bare lagt til en enkelt fil. Hvis vi i stedet foretrekker å legge til alle filer i oppsamlingsområdet, kan vi bruke periodesymbolet.
git add .
Husk at lastebilen ennå ikke har gått; Vi har bare lagt et par bokser (eller filer) inn i ryggen. For å utføre stillbildet, og lagre en kopi av prosjektet i den nåværende spore tilstanden, må det utføres en forpliktelse.
git commit -m 'Først begå'
Ovenfor har vi opprettet en ny commit og gitt en melding om "First commit." Med det har vår første forpliktelse fullført, og trucken har forlatt fabrikken, med en kopi av prosjektet på baksiden.
For å bekrefte arbeidet ditt, bruk en ny kommando: "logg".
git logg forpliktelse 02c934fcaf3de7677273b74d8ad3ed5041066986 Forfatter: Jeffrey Way Dato: ons 19 desember 15:07:23 2012 -0500 Første forpliktelse
Perfekt, en ny forpliktelse er faktisk blitt opprettet, og det ser også ut til at forplikten har et unikt referansjons-ID. Fil som er borte for nå.
Hvis du igjen kontrollerer statusen.
git status
Fordi ingen endringer har blitt gjort siden siste forpliktelse, forteller Git oss så mye:
# På grenmesteren ingenting å begå (arbeidskatalog ren)
Suksess! 90% av Git-bruken din følger denne syklusen.
Gjøre endringer
Legg til filer i staging-området
Utfør en forpliktelse med en melding som beskriver handlingen som fant sted
Skyll og gjenta!
La oss gå videre til neste trinn. Som et enkelt eksempel, kanskje vi vil inkludere et enkelt reset stilark i prosjektet vårt. Vi skriver de mest grunnleggende (kanskje dårlig anbefalte) tilbakestillinger.
Gå nå tilbake til index.html, og ta med en referanse til denne filen:
Som en grunnleggende tommelfingerregel, hvis du kan beskrive til personen som sitter ved siden av deg, hva endrer du nettopp til et prosjekt, fortjener det sannsynligvis en forpliktelse. Forplikte seg ofte. La oss gjøre det nå; tilbake til terminalen!
git add. git commit -m 'Legg til og inkludere tilbakestille stilark.'
Når du skriver forpliktende meldinger, anses det generelt for å være best praksis å skrive i dagens tid. Så, "legg til fil" i stedet for "lagt til fil."
Raskt frem til i morgen, og nå sjefen din forteller deg at de ikke vil bruke din enkle nullstillingsfil. I stedet vil de foretrekke å bruke det populære Normaliser stilarket, av Nicolas Gallagher.
Ikke noe problem; med Git, dette er en enkel løsning. La oss gå tilbake til forrige forpliktelse, og foreta de nødvendige endringene.
Git tilbake HOVED
Med Git er regelen "aldri omskrive historie".
Denne kommandoen vil reversere alle endringene du har gjort i den siste forpliktelsen. I hovedsak er det en forpliktelse som gjør det motsatte mot det som den forrige gjorde. Hvorfor gå tilbake, i stedet for å fortrykke fullbyrdelsen helt? Igjen, fordi vi følger beste praksis. Med Git er regelen "aldri omskrive historie". Tilbakestill endringene, men slett aldri og slett dem.
Ved å trykke inn, blir du tatt med til en ny skjerm med teksten, "Tilbakestill" Legg til og inkludere tilbakestill stilark. " På dette tidspunktet er du i Vi-modus (selv om du er ledig til å konfigurere Git til å bruke hvilken som helst koderedigerer du ønsker.) For nå, gå til standardene, lagre og avslutt. Oppnå dette ved å skrive: wq (Write and Quit).
Og med den ene kommandoen, har endringene blitt tilbakeført. Gå videre og sjekk for å være sikker. Style.css-filen er fjernet, og det er ikke lenger en referanse til stilarket innenfor index.html. Dette er kraften til Git! Fordi vi vedtok en utviklingsstil å begå ofte, når de plasseres i situasjoner, der endringer må reverseres, tar det bare en enkelt kommando. Ikke mer trykke Kommando-Z for enternity!
Etter sjefens forespørsel, la oss oppdatere prosjektet for å bruke Normalize.css, som vi har lastet ned og plassert innenfor css / normalize.css.
Innenfor index.html, referer det til:
Og til slutt forplikter vi endringene.
git add. git commit -m "Inkluder Normaliser i prosjekt"
Selv om dette var et enkelt eksempel, kan du forestille deg hvor nyttig denne teknikken kan være for større endringer, som spenner over flere filer i søknaden din. Ved å gruppere alle relaterte endringer i en enkelt forpliktelse, oppnår vi maksimal fleksibilitet og sikkerhet.
Rom til eksperiment
Har du noen gang vært på et punkt i et prosjekt, når du vil eksperimentere med en ide som kan eller ikke gjør det til det ferdige programmet? Selv om det er sant at du alltid kan vende tilbake forpliktelsen hvis ting ikke går i henhold til planen, er det en smartere ide, av en rekke grunner, å isteden utnytte forgrening.
Den beste måten å illustrere begrepet Git-grener på er å referere til Tilbake til fremtiden 2.
På den måten, hvis du er en nerdy utvikler og ikke har sett trilogien Tilbake til fremtiden, må du stoppe hva du gjør og se på dem!
Fortsett med, husk delen i Tilbake til fremtiden 2, etter at Marty og Doc kommer tilbake til 1985 fra fremtiden, men finner at alt er annerledes? Ved å møte på Docs, nå ødelagte lab, tegner Doc et diagram som beskriver hvordan, på et tidspunkt, "tidslinjen skjedde i denne tangenten, og skaper en alternativ 1985." Dette er akkurat som forgrening!
Vurder vår nåværende demo prosjekt; akkurat nå er det en tidslinje: en rett linje. Så snart vi lager en gren for å jobbe med vår ide, bryter vi vekk fra denne tidslinjen, og oppretter en annen. På dette punktet eksisterer begge tidslinjer, og kan inneholde sine egne respektive forpliktelser uten å forstyrre hverandre.
Hvordan er dette nyttig? Overvei en fleksibel utviklingssyklus - en der du eller ditt team distribuerer oppdateringer flere ganger hver uke. Hvis du holder deg til "single timeline" -tilnærming, vil det for eksempel ikke være mulig å utføre en enkel skrivefeil, før du er ferdig med å jobbe med ideen din også. Med forgrening har vi imidlertid fleksibiliteten til å ta så lenge vi trenger på vår ide, mens du fremdeles frigjør master-grenen (standard og primær) for å distribuere typografipakken.
For å opprette en ny avdeling, kjør:
$ git branch idé $ git kassen ideen
Alternativt kan du kombinere disse to kommandoene i en.
git checkout-b ide
Dette oversetter til: Opprett en ny grenen, kalt "ide" (erstatt dette for å være mer beskrivende av hva du jobber med, selvfølgelig), og bytt til det.
Fra dette tidspunktet vil eventuelle endringer og forpliktelser du gjør ikke bli referert i hovedgrenen. Fortsett, prøv det. Rediger index.html og gjør en liten endring:
Min idé
Deretter forplikte arbeidet ditt.
git legg til index.html git commit -m 'Første utkast til ideen min'
Vi har nå gjort vår første forpliktelse i denne nye tidslinjen. Vår fiktive ide trenger fortsatt arbeid, men vi er på vei! Men nå rapporterte en kunde bare en skrivefeil som vi må fikse så snart som mulig. Fordi vi bruker filialer riktig, kan vi gå tilbake til hovedgrenen, fikse tastaturet og distribuere den.
git checkout mester # fix typo git legg til index.html git commit -m 'Fix liten skrivefeil' git push
Når vår ide-funksjon er ferdig, er det på tide å fusjonere det tilbake til hovedgrenen.
git checkout master git fusjon ideen
Hvis alt går i henhold til planen, vil funksjonsgrenen din bli slått sammen igjen i hovedgrenen, og løsningen av den andre andre 1985-tidslinjen!
Når det er sagt, vil du uten tvil komme over situasjoner når Git tilsynelatende planter føttene i bakken, og nekter å fortsette som spurt. I disse tilfellene, er Git ikke en rykk uten grunn! Mest sannsynlig er problemet knyttet til en konflikt som først må løses, før Git kan fortsette. Tenk deg å forsøke å slå sammen en fil tilbake til hovedgrenen; Det eneste problemet er at siden filialen ble opprettet, har filen blitt redigert i både funksjonen grenen, samt mesteren. I situasjoner som dette, hvordan kan Git muligens vite hvilken versjon av filen som skal ta forutsetning, når man smelter sammen de to? Det gjør det ikke, og det er det vi kaller en konflikt.
Automatisk sammensmelting index.html KONFLIKT (innhold): Slå sammen konflikt i index.html Automatisk fletting mislyktes; fikse konflikter og deretter begå resultatet.
Før Git kan fortsette, må du løse konflikten ved å redigere index.html.
Ignorerer filer
Det kommer sannsynligvis et poeng når du bestemmer at det er best å ikke spore visse filtyper med Git. Eksempler kan omfatte felles .DS_STORE (hvilke Mac-brukere vil bli kjent med), bygge kataloger og midlertidig sammensatte eiendeler.
Enkelt nok tillater Git, via en .gitignore-fil, å ignorere visse filtyper. For å gjøre bruk av dette, opprett en ny .gitignore-fil i roten (men ikke begrenset til) av prosjektet ditt. Innenfor det, gi en liste over filer eller filtyper for å ignorere. Her er et grunnleggende eksempel:
.DS_STORE build / * .log * .sql * .exe
Sosial koding
GitHub gjør sosial koding mulig.
Så langt har du lært å forplikte koden lokalt. Men hvordan kan disse endringene bli delt med enten teamet ditt eller resten av verden? Skriv inn GitHub.
GitHub lar deg dele koden med verden. Det er det største open source-samfunnet som eksisterer.
Når du registrerer deg for en ny konto på github.com, må du følge noen få trinn for å generere en spesialnøkkel, for å knytte datamaskinen til din GitHub-konto. Ikke bekymre deg; Hvis du følger trinnene, bør du ikke ha noen problemer.
På dette tidspunktet kan vi opprette et nytt lager, og presse vårt lille prosjekt, for å dele det med verden. Når du er logget inn, klikker du på "Ny Repository" -knappen, gi repo et navn, og klikk "Create Repository." Deretter blir du presentert med noen få kommandoer som kan limes inn i Terminal. Som vi allerede har en eksisterende repo, trenger vi det andre alternativet:
Dette instruerer Git til å legge til vårt nye fjernlager, og alias det som "opprinnelse". Deretter skyver vi hovedgrenen (ikke ideen) til fjernkontrollen med aliaset "opprinnelse".
Det er det! Gå tilbake til nettleseren, oppdater siden, og du finner ditt friske nye lager, og venter på å bli delt med resten av verden.
Når andre medlemmer av teamet ditt ønsker å trekke inn endringene du har gjort, trenger de bare å kjøre:
git pull
Denne kommandoen trekker inn de siste oppdateringene som har blitt presset til GitHub! I tillegg til delingskode, tilbyr GitHub også muligheten til å spore og bidra til populære åpne kildeprosjekter, samt et problemspor for feil og funksjonsforespørsler. Det er sosial koding når det er best!
Avsluttende tanker
Selv om vi bare har kløftet overflaten av hva Git er i stand til, er sannheten at igjen, for 80% av Git-bruken din, vil teknikkene referert til i denne artikkelen være tilstrekkelig. Opprett en avdeling, skrive noen kode, legg den til staging-området, og legg den inn med en melding. Når du er klar, slå den sammen igjen i hovedgrenen og distribuere! Skyll deretter og gjenta!
Ikke glem: StackOverflow er din beste venn når stumped. Uansett hva problemet kan være, har andre vært i nøyaktig samme situasjon. Søk det først.
Share
Accentsconagua
