Med mindre du er en enhets nettbutikk uten team til å samarbeide med, har du opplevd frustrasjonen som følger med fildeling. Uansett hvor hardt du prøver, når flere personer jobber på et enkelt prosjekt uten et versjonskontrollsystem på plass, blir ting kaotisk .

Hvis du jobber med utviklere på utbygging og implementering av nettsteder, kan sammenslåingen mellom front-end maler og back-end-funksjonalitet være et skummelt svart hull.

Problemer som overskriver, tapt filer, og altfor-vanlig "jobber av en tidligere versjon" -fenomen kaster opp hele tiden . Og når back-end-funksjonalitet er satt inn i maler, blir du redd for å berøre dem for frykt for å bryte noe som en utvikler har brukt mye tid på å komme seg til jobb.

I tillegg, selv om du har et felles depot som alle trekker fra odds, er minst ett medlem av teamet ditt glemt å ta tak i de nyeste filene og er i ferd med å blåse opp med de nyeste tilleggene.

I denne artikkelen gir jeg deg en rask gjennomgang av Git, et utmerket versjonskontrollsystem .

Versjonskontroll - En rask og skitten forklaring

Versjonskontroll (også kjent som Revision Control eller Source Control Management ) er en fin måte å løse fildelingsproblemet på.

Det grunnleggende konseptet er dette: det er ett hovedregister for alle prosjektfiler . Lagmedlemmer sjekker ut filer, gjør endringer, og deretter sjekker dem tilbake (eller begår dem). Versjonskontrollsystemet (VCS) registrerer automatisk hvem som endret filene, da de ble endret, og hva med dem var nytt eller annerledes.

Det ber deg også om å skrive et lite notat om endringen slik at alle på prosjektet vet et øyeblikk hva du gjorde og hvorfor. Hver fil vil da ha en revisjonshistorikk, slik at du enkelt kan gå tilbake til en tidligere versjon av en fil hvis noe går galt feil.

En god VCS lar deg også slå sammen endringer i samme fil . Hvis du og en annen person jobber lokalt på samme fil samtidig, når du trykker disse filene tilbake i hovedregisteret, vil systemet fusjonere begge settene med endringer for å opprette en ny og fullstendig oppdatert fil. Hvis det oppstår konflikter under fusjonen, vil det fremheve dem for deg.

Du bruker sannsynligvis en veldig rå VCS akkurat nå for å holde filene dine rett. Hvis du er designer, ser det slik ut:

dpcwqxg_312gvhkh4s6_b

Designer Versjonskontroll - Feil

Dette fungerer godt nok for PSDer og andre store binære filer, som egentlig ikke gir seg til VCS. Men det er en mye bedre måte å gjøre det når du administrerer kildekoden for et nettsted.

Fordeler ved bruk av et versjonskontrollsystem inkluderer:

  • Filer kan ikke skrives over
  • Det finnes et felles lager som inneholder alle de nyeste filene
  • Folk kan jobbe på de samme filene samtidig uten konflikt
  • Lar deg gå tilbake til en eldre versjon av filen / prosjektet hvis det er nødvendig
  • Gjør utviklerne veldig fornøyde

Selv om du ikke jobber med et lag, kan versjonskontroll være en livredder . Sikkerhetskopiering av filer er en av de enkleste tingene du kan gjøre for å redde deg fra å miste arbeid eller måtte begynne igjen.

Ideen om en VCS virker skremmende i begynnelsen, spesielt siden det meste av dokumentasjonen er skrevet av og for utviklere . Men når du gjør flyttingen til å inkorporere den i arbeidsflyten din, finner du det ikke nesten like hardt som det ser ut.

dpcwqxg_322grqgzjcz_b

Møt Git

OK, så nå kan du se hvorfor et Versjonskontrollsystem er et must-ha for ditt webteam. Hvis du gjør litt Googling, ser du at det er mange alternativer der ute, inkludert SVN, Mercurial, CVS, Bazaar og Git. Enhver av dem kan være en god løsning for dine behov, og jeg oppfordrer deg til å gjøre noen undersøkelser før du velger en VCS. I denne artikkelen skal jeg fokusere på Git , den jeg bruker daglig. Det er en "stigende stjerne" som har blitt populær takket være en sterk Linux fanbase, GitHub og rails samfunnet.

Git er et gratis, åpen kildekode Versjonskontrollsystem opprinnelig opprettet av Linus Torvalds for Linux-kjerneutvikling. Linus er en veldig smart fyr; når han setter seg ut for å løse et problem, knuser han ikke rundt. En av Gits store differensierer er at i motsetning til SVN og CVS er det a distribuert versjon kontrollsystem . Dette betyr at hver bruker har en komplett kopi av lagerdataene som er lagret lokalt på maskinen sin. Hva er så bra med det? Noen få ting:

    • Alt er lokalt , så du kan jobbe offline
    • Det er ikke et eneste punkt i feil . Det stole ikke på en sentral server som kan krasje og brenne, og tar det eneste lagringsplasset for prosjektet med det.
    • Fordi det ikke trenger å kommunisere med en sentral server hele tiden, går prosessene mye raskere

      Git har en litt tøffere lærekurve enn SVN , men bytte er verdt det. Tenk bare hvor imponert utvikleren din vil være når du forteller dem at du bruker den nye hotnessen som er Git! I all alvor tror jeg ikke at lærekurven er så bratt. SVN var like forvirrende for meg i starten, og jeg løp inn i flere daglige problemer når jeg brukte den.

      Installere Git er ikke moro og spill. Jeg var heldig å ha en kunnskapsrik utvikler villig til å hjelpe, men det er mange ressurser på nettet for å få deg gjennom det. Den kjører på en PC, Mac eller Linux-boks, selv om installasjon for Linux og OSX er betydelig enklere enn for Windows.

      Du kan laste ned den nyeste versjonen av Git her Når du har filene, prøv dette hurtiginnføring for å komme i gang med installasjonsprosessen. For Windows-brukere, dette trinn-for-trinn visuell guide bør være nyttig. Mac-brukere, prøv denne veiledningen funnet på GitHub

      Starter

      Når du har installert Git, kan du opprette depotet ditt . Hvis du vil slå en eksisterende mappe til et Git-depot, bruker du følgende kommandoer i vinduet Terminal eller Kommandoprompt:

      cd path/to/projectgit initgit add .git commit

      Hva du forteller Git å gjøre er:

      • Initialiser denne katalogen
      • Legg alt i det - alle filer og underkataloger
      • Forplikte eller lagre , alle gjeldende endringer i depotet

      Hvis du hater kommandolinjen, kan du også gjøre dette ved å bruke Git GUI . Det er ikke den vakreste tingen du noensinne har sett, men det er der hvis du trenger det.

      Et skjermbilde av Git GUI

      En prøve Git-arbeidsflyt

      Jeg bruker for øyeblikket Git på en Mac for å jobbe med et webprogram med flere webutviklere. Vi har en "master" -versjon av koden vi skyver filene våre til, og vi kjører hver en full kopi lokalt. På en gitt dag går arbeidsflyten min noe slikt:

      dpcwqxg_323gnhgbwg3_b

      1. Brann opp Terminal . Start opp min lokale mysql-database (slik at programmet vi bygger kan kjøre lokalt på min maskin).
      2. Bruk Terminal for å sjekke ut de siste endringene ved å bruke kommandoen "Git pull" . Dette gir meg alle endringene laget av andre lagmedlemmer og sjekket inn i vårt mesterregister.
      3. Åpne prosjektet i TextMate og foreta endringene mine.
      4. Forbind endringer og legg til notatene mine . Dette forplikter seg bare lokalt. Jeg forplikter meg ofte, sannsynligvis ti eller flere ganger om dagen. Dette bidrar til å holde meg på sporet.
      5. Trykk på endringene i mastereposten med "Git push" . Nå kan andre lagmedlemmer sjekke ut og se endringene mine. Du bør gjøre dette minst en gang om dagen eller etter et stort tillegg.

      Alle disse handlingene kan gjøres enkelt gjennom Terminal-vinduet , men jeg er en visuell slags jente. Derfor bruker jeg GitX , en Git gui for OSX , for å gjøre mine forpliktelser. Jeg presser fortsatt og trekker gjennom Terminal, men GitX gjør det enkelt for meg å organisere mine forpliktelser og vikle hodet mitt rundt hva jeg gjør.

      GitX Skjermbilde
      På toppen av det fremhever det hvilken endring som ble gjort på filene. Nederst til venstre er listen over uendrede endringer . For å begå dem, drar du en eller flere filer til "Staged Changes" -området til høyre, skriv inn commit-meldingen din og trykk på Commit-knappen.

      Hvis jeg svinger til trevisningen, kan jeg se hva som har blitt presset til depotet. Hvis filene mine ikke var aktuelle med hovedfilene, ville de grønne og blå kodene øverst være synkronisert. GitNub tilbyr et lignende grensesnitt for Mac-stil.

      GitX Skjermbilde
      Det er også en flott TextMate-pakke tilgjengelig. Med det kan du trykke, trekke, begå og mer uten å forlate TextMate. Det er ekstremt effektivt.

      TextMate med Git Bundle installert

      Lære mer

      Git Cheat Sheet

      Git Cheat Sheet av Zack Rusin

      Ovenfor: Zack Rusins ​​Git Cheat Sheet

      Jeg er fortsatt en nybegynner å Git meg selv, så jeg har bare ripet overflaten på hva du kan gjøre med det, men jeg har definitivt sett lyset når det gjelder versjonskontroll og er glad jeg endelig fikk på bandwagon.

      For å lære mer om å bruke Git, sjekk ut disse gode ressursene:

      Intros å Git

      Bli kjent med Git
      Wikipedia oppføring på Git
      Hvorfor Git er bedre enn X
      Linus Torvalds TED-snakk på Git
      En tur til Git: Grunnleggende
      Git Ready

      Cheat Sheets / Tips

      37 Signaler Git Resources
      Git For The Lazy
      Brukerhåndboken for Git
      En Gaggle Git Tips
      GitHubs Git Cheat Sheet
      Git Magic

      Intros til Versjonskontroll

      Versjonskontroll for designere
      En visuell veiledning til versjonskontroll
      Wikipedia oppføring på Revision Control
      Velge et distribuert versjonskontrollsystem
      Jeg lurer på hva denne knappen gjør (en liste fra hverandre)


      Skrevet utelukkende for WDD av Mindy Wagner. Hun er webdesigner hos Viget Labs og har jobbet i både print og webdesign i over 8 år. Hun har en grad i elektronisk media kunst og kommunikasjon fra Rensselaer Polytechnic Institute.

      Bruker du Git eller annen programvare for versjonskontroll? Vennligst del din erfaring med oss!