Grundprincipper og sprogbrug<\/h3>\n\n\n\n
Grundprincippet i git er, at man har et repository <\/strong>– i daglig tale et repo <\/strong>– som overv\u00e5ges af git. Alle \u00e6ndringer registreres i r\u00e6kkef\u00f8lge og efter hvem der laver dem. Man arbejder p\u00e5 filerne som normalt, og retter og gemmer undervejs, men n\u00e5r man p\u00e5 et tidspunkt er f\u00e6rdig, s\u00e5 fort\u00e6ller man git, at “her er noget du skal huske” – man committer<\/strong> \u00e6ndringerne til git (og man committer sig til \u00e6ndringerne). Nu laver git en note om hvem og hvorn\u00e5r, samt en liste over forskellene mellem den gamle og den nye version.<\/p>\n\n\n\n Det smarte med git er i virkeligheden at bruge det sammen med GitHub . Mens git kan holde styr p\u00e5 mapper og filer lokalt p\u00e5 din computer, tager GitHub funktionaliteten ud p\u00e5 nettet. Du kan t\u00e6nke p\u00e5 GitHub som en slags dropbox for programm\u00f8rer. Men I kan ikke kun dele jeres filer i skyen. Med git og GitHub har I fuld kontrol over hvem der retter og \u00e6ndrer dem, hvorn\u00e5r de g\u00f8r det og ikke mindst hvorfor. Og I er sikre p\u00e5, at hvis der er konflikt mellem \u00e6ndringsforslag, s\u00e5 bliver det opdaget – I kommer ikke til at slette hinandens arbejde ved et uheld.<\/p>\n\n\n\n N\u00e5r man bruger GitHub, har man sit repo p\u00e5 nettet, p\u00e5 en GitHub-konto. Det kaldes origin<\/strong> eller remote<\/strong>, mens den mappe lokalt p\u00e5 maskinen, som man arbejder i, kaldes local<\/strong>. Git holder styr p\u00e5, om filerne i den lokale mappe er identiske med origin<\/strong> eller om de er forud eller bagud for rettelser p\u00e5 GitHub. <\/p>\n\n\n\n Det man arbejder p\u00e5 er i reglen filerne i den lokale mappe. Der hekser man rundt, retter og pr\u00f8ver sig frem, indtil man er tilfreds. Imens gemmer man hele tiden mellemresultaterne – men de skal jo ikke op til andre. F\u00f8rst n\u00e5r man har noget, der virker tilstr\u00e6kkelig godt, vil man have nye filer og \u00e6ndringer lagt op. S\u00e5 laver man et commit<\/strong>, og skriver samtidig en lille note om, hvad det er for en \u00e6ndring. GitHub noterer, at disse filer skal l\u00e6gges op p\u00e5 origin<\/strong>. Man siger, at \u00e6ndringerne er staged<\/strong> – alts\u00e5 sat i scene, lagt til rette for at blive uploaded.<\/p>\n\n\n\n N\u00e5r du har rodet med dit repo lokalt og staged<\/strong> dine forbedringer, og derp\u00e5 vil l\u00e6gge det hele ud til andre p\u00e5 GitHub.com, kaldes det at pushe<\/strong>. Der er alts\u00e5 generelt tre trin i den samlede proces, og i konsollen ville det se s\u00e5ledes ud:<\/p>\n\n\n\n Eftersom GitHub ligger p\u00e5 nettet, er det ofte s\u00e5dan at nogle andre har modificeret koden, eller du har m\u00e5ske selv arbejdet med den p\u00e5 en anden computer. Derfor er det ofte en god id\u00e9 at starte med et pull<\/strong>, hver gang du starter, f\u00f8r du arbejder videre lokalt. P\u00e5 den m\u00e5de er du sikker p\u00e5 dine lokale filer svarer til filerne p\u00e5 GitHub. <\/p>\n\n\n\n G\u00e5 ind p\u00e5 github.com<\/a> og opret en konto, f\u00f8r du g\u00e5r videre. Du har nu en tom GitHub konto. N\u00e6ste skridt er at f\u00e5 etableret dit f\u00f8rste repo, enten ved at linke kontoen op til de filer p\u00e5 lokalt p\u00e5 din maskine, som du vil have som dit lokale git-repository eller ved at skabe et repo p\u00e5 GitHub, som du derefter cloner<\/strong> ned til din egen maskine.<\/p>\n\n\n\n Der er mange forskellige m\u00e5der at komme til at arbejde med git og GitHub p\u00e5. Mange arbejder i en “shell”, alts\u00e5 et konsolvindue med tekstkoder direkte til maskinen, men de fleste foretr\u00e6kker at bruge et program med et interface – jeg g\u00f8r. Et s\u00e5dant interface er GitHub Desktop, som vi kigger p\u00e5 her. Visual Studio Code kan ogs\u00e5 s\u00e6ttes op til at integrere med GitHub s\u00e5 \u00e6ndringerne trackes og synkroniseres med filerne p\u00e5 nettet, men VSCode bruger i virkeligheden GitHub Desktop “bagved”. Unity kan s\u00e5dan set ogs\u00e5 integrere med GitHub, men deres system er ikke blevet opdateret i flere \u00e5r. <\/p>\n\n\n\n G\u00e5 ind og hent programmet GitHub<\/a> Desktop her<\/a>. Herefter er der tre forskellige situationer, der kan v\u00e6re aktuelle: <\/p>\n\n\n\n I GitHub Desktop skal du f\u00f8rst s\u00f8rge for at v\u00e6re logget p\u00e5 din GitHub konto, derefter kan du tilf\u00f8je dit lokale repository. V\u00e6lg add\/create new repository for at lave et nyt git-repo ud af en projektmappe (add\/add existing repository, hvis git allerede er i brug, men det finder Desktop selv ud af). <\/p>\n\n\n\n Du kan nu “committe<\/strong>” til dit GitHub repository, dele det med andre og i det hele taget arbejde videre som vanligt. <\/p>\n\n\n\n Du kan lade git v\u00e6lge at ignorere visse filer, som alts\u00e5 ikke bliver lagt ud p\u00e5 nettet, men bare bliver lokalt p\u00e5 computeren. <\/p>\n\n\n\n Hvis du har arbejdet med node.js, python eller andre st\u00f8rre programmeringssprog, ved du at de ofte har pakker og biblioteker som skal installeres, f\u00f8r et program kan fungere. I node.js projekter ligger der for eksempel altid en fil som hedder package.json, som fort\u00e6ller n\u00f8jagtig hvilke biblioteker projektet er afh\u00e6ngig af (dependencies). <\/p>\n\n\n\n I stedet for at uploade alle disse filer til GitHub, er det meget smartere at lade andre der har downloadet din kode kigge i package.json f\u00f8r de g\u00e5r i gang – og s\u00e5 hente filerne n\u00e5r der er brug for dem. Derfor er det god stil at fort\u00e6lle git, at dit repo er eksempelvis et “node” projekt, et “unity” projekt eller et “python” projekt, s\u00e5 springer det automatisk over alle de filer, som andre kan hente selv. <\/p>\n\n\n\n P\u00e5 GitHub selv er der faktisk en side dedikeret netop til .gitignore: https:\/\/github.com\/github\/gitignore<\/a>, som har templates til .gitignore-filer for stort set alle former for IT-udvikling. Processing, Node og Unity er med – og listen er meget lang. Forneden p\u00e5 denne GitHub-side er der mere information.<\/p>\n\n\n\n Git og GitHub er faktisk ikke kun til open-source projekter. Man kan oprette private repos og bruge dem til propriet\u00e6r kode, og der er ogs\u00e5 betalingsmodeller tilknyttet GitHub. <\/p>\n\n\n\n N\u00e5r du uploader et nyt repo til GitHub er det derfor helt centralt at du beslutter dig for hvilken licens du vil bruge. Licenser er der mange af, og det kan v\u00e6re sv\u00e6rt at vide hvad man skal v\u00e6lge. Jeg bruger selv MIT License<\/a>. Det er en meget liberal software licens, som faktisk tillader andre at bruge min kode kommercielt – s\u00e5 l\u00e6nge de bare s\u00f8rger for at putte samme licens p\u00e5 deres software. <\/p>\n\n\n\n Hvorvidt denne liberale software opfattelse<\/a> bliver ved med at holde i det 21. \u00e5rhundrede, kan man dog have sin tvivl om. Men indtil videre…<\/p>\n\n\n\n N\u00e5r du henter et eller andet, kaldes det at “clone<\/strong>” et repository. At clone er den mindst invasive m\u00e5de at hente noget p\u00e5 – det betyder bare: giv mig en lokal kopi, jeg kan g\u00f8re hvad jeg vil med. Pr\u00f8v at clone det her repo fra GitHub<\/a>. Det stammer fra Daniel Shiffmans fremragende pr\u00e6sentation af GitHub,<\/a> som du forresten ogs\u00e5 kan v\u00e6lge at se i stedet for at l\u00e6se alt dette. <\/p>\n\n\n\n Github er fantastisk fordi du lynhurtigt kan snuppe andres kode, og se hvordan alt muligt fungerer. Du kan for eksempel hente den fuldkommen \u00e5bne kode til Linux<\/a>. Eller til et hav af andre projekter<\/a>. Skulle du have en dag i overskud, kan man sagtens f\u00e5 tid til at g\u00e5 med bare at sidde og hente GitHub projekter og s\u00e6tte dem op p\u00e5 sin egen computer. <\/p>\n\n\n\n Og t\u00e6nke over hvordan du kunne modificere koden. Afh\u00e6ngig af licensen – som meget ofte er forskellige udgaver af liberale opensource paradigmer – kan du for det meste downloade alt hvad du finder og bruge det frit i dine egne projekter. I det \u00f8jeblik du vil tjene penge p\u00e5 det, skal du dog tjekke licensen en ekstra gang. <\/p>\n\n\n\n N\u00e5r du har clonet et repo, kommer det over i din lokale git-mappe. Se om du kan f\u00e5 hentet, \u00e6ndret og committet og pushet et eller andet til din egen GitHub, f\u00f8r du g\u00e5r videre. Men duhar ikke n\u00f8dvendigvis skriverettigheder p\u00e5 det repo, du har clonet fra. Hvis du har – eller f\u00e5r – rettigheder til det, fx. fordi det er en af dine gruppekammeraters repo og jeres f\u00e6lles projekt, s\u00e5 kan du pulle, committe og pushe som f\u00f8r. Hvis ikke du har rettigheder, kan du i stedet oprette en fork<\/strong> af repo’et – alts\u00e5 en kopi, som ligger p\u00e5 din GitHub p\u00e5 nettet, og som du kan modificere som det passer dig. Det er det, I skal g\u00f8re, n\u00e5r vi linker til skolens eller fagets GitHub til materialer, I skal hente.<\/p>\n\n\n\n Lad os sige du havde rodet med noget kode fra et GitHub repo du har klonet og forket. P\u00e5 et tidspunkt finder du s\u00e5 en fejl. Du retter den! Hvordan kan du nu hj\u00e6lpe koderen til at f\u00e5 fejlen rettet i det oprindelige repo? Du opretter en pull-request<\/strong>, som er en anmodning til ejeren af koden og det oprindelige repo om, at han\/hun skal pull’e dine \u00e6ndringer. Ejeren f\u00e5r s\u00e5 en notifikation og med mindre han\/hun tror du er terrorrist, f\u00e5r du lov til at f\u00e5 en (begr\u00e6nset) adgang. Du kan nu rette fejlen i koden, og fors\u00f8ge at committe koden tilbage til den originale version. Nu vil ejeren s\u00e5 have mulighed for at kigge din rettelse igennem (review)<\/strong>, og eventuelt “merge<\/strong>” den ind i sin egen kode. <\/p>\n\n\n\n GitHub er ogs\u00e5 et samarbejdsv\u00e6rkt\u00f8j. Hvis I er flere i en gruppe, kan I arbejde i et f\u00e6lles repo p\u00e5 en af jeres GitHub-kontoer, og ejeren af den konto kan invitere jer andre gitHub-brugere som “collaborators<\/strong>” s\u00e5 I alle kan pushe \u00e6ndringer op. Der er ogs\u00e5 v\u00e6rkt\u00f8jer til projektstyring, til at tracke issues og meget andet.<\/p>\n\n\n\n Bem\u00e6rk, at man IKKE kan clone et repo fra GitHub ned i en lokal mappe, hvor der allerede ligger filer. Man kan alts\u00e5 ikke “supplere” sin egen projektmappe med filer fra andres GitHub repo ved at clone. I stedet kan man eventuelt downloade repo’et som en zip-fil og pille de filer ud, man skal bruge.<\/p>\n\n\n\n Det er ikke uden risiko, hvis alle bare kan pushe \u00e6ndringer op til det f\u00e6lles projekt uden videre. Man risikerer, at \u00e6ndringer et sted breaker noget et andet sted, s\u00e5dan at det, der k\u00f8rte i g\u00e5r, pludselig ikke l\u00e6ngere duer. Derfor arbejder man gerne med branches<\/strong>, dvs. “grene” eller “varianter”af koden, hvor man opretter en branch til at arbejde med specifikke aspekter – UI, netv\u00e6rk, modeller, platforme – men s\u00f8rger for at have en “stabil” version: master branch<\/strong>, som fungerer, og som man f\u00f8rst retter i, n\u00e5r man er sikker p\u00e5 at rettelserne duer. Det vil sige at man pusher til en branch p\u00e5 GitHub, og n\u00e5r rettelserne er set igennem (reviewed<\/strong>) kan man v\u00e6lge at oprette en pull request<\/strong> for at merge<\/strong> denne branch ind i master<\/strong>. P\u00e5 den m\u00e5de kan mange personer arbejde p\u00e5 mange forskellige dele af projektet uden at g\u00e5 i vejen for hinanden.<\/p>\n\n\n\n Man v\u00e6lger hvilken branch man vil pushe til (eller pulle fra) i GitHub Desktop. Teknisk set er det s\u00e5 denne branch, ikke repo’et som s\u00e5dan, der er “origin<\/strong>“. Og det kan v\u00e6re en god ide at s\u00e6tte GitHub repo’et op s\u00e5dan at det simpelthen ikke er muligt at pushe direkte til master, s\u00e5ledes at rettelser i master kun kan forekomme efter review og merge.<\/p>\n\n\n\n Hvis man skal til at starte et helt nyt projekt, bliver tingene nemmere hvis man starter med at s\u00e6tte GitHub-repo’et op. Hvert repo har sin egen mappe p\u00e5 jeres GitHub konto, s\u00e5 hvis man skal starte et projekt fra grunden er en m\u00e5de at oprette et nyt n\u00e6sten tomt repo p\u00e5 GitHub og s\u00e5 clone det. Man kan ogs\u00e5 g\u00f8re det lokalt fra GitHub Desktop ved at oprette et nyt repo hvor man s\u00e5 angiver b\u00e5de local og remote placering\/sti.<\/p>\n\n\n\n Et repo<\/strong> er en mappe hvor git holder \u00f8je med \u00e6ndringer<\/p>\n\n\n\n At committe<\/strong> er at fort\u00e6lle git, at nu er man klar med sine rettelser, og git skal f\u00f8je dem til projektet<\/p>\n\n\n\n At forke <\/strong>er at kopiere en andens projekt ind i din egen konto p\u00e5 GitHub<\/p>\n\n\n\n At clone <\/strong>er at kopiere et projekt fra GitHub ned p\u00e5 sin egen computer<\/p>\n\n\n\n At fetche <\/strong>er at hente forandringer \u2013 men UDEN at \u00e6ndre dine filer lokalt<\/p>\n\n\n\n En branch <\/strong>er en udgave af et repo der er blevet clonet lokalt<\/p>\n\n\n\n En remote branch<\/strong> er dette repo n\u00e5r den ligger p\u00e5 GitHub (kendes lokalt som origin)<\/p>\n\n\n\n At merge<\/strong> er at flette en branch ind i en anden<\/p>\n\n\n\n En konflikt <\/strong>er n\u00e5r man vil pulle noget ned, som ikke svarer til det man har lokalt, og hvor der er modsat rettede \u00e6ndringer i de samme kodelinjer<\/p>\n","protected":false},"excerpt":{"rendered":" Git I disse moduler bliver du introduceret til et helt centralt samarbejdsredskab indenfor software udvikling: git. Git er et v\u00e6rkt\u00f8j til source control. N\u00e5r man programmerer og laver st\u00f8rre it-projekter i det hele taget, er det supervigtigt at have styr p\u00e5 hvilke \u00e6ndringer i koden der er lavet i hvilken r\u00e6kkef\u00f8lge, og af hvem. Det skal v\u00e6re … L\u00e6s mere <\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22],"tags":[],"class_list":["post-4352","post","type-post","status-publish","format-standard","hentry","category-tools"],"_links":{"self":[{"href":"https:\/\/digitalteknik.slotshaven.it\/wordpress\/wp-json\/wp\/v2\/posts\/4352","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/digitalteknik.slotshaven.it\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/digitalteknik.slotshaven.it\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/digitalteknik.slotshaven.it\/wordpress\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/digitalteknik.slotshaven.it\/wordpress\/wp-json\/wp\/v2\/comments?post=4352"}],"version-history":[{"count":0,"href":"https:\/\/digitalteknik.slotshaven.it\/wordpress\/wp-json\/wp\/v2\/posts\/4352\/revisions"}],"wp:attachment":[{"href":"https:\/\/digitalteknik.slotshaven.it\/wordpress\/wp-json\/wp\/v2\/media?parent=4352"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/digitalteknik.slotshaven.it\/wordpress\/wp-json\/wp\/v2\/categories?post=4352"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/digitalteknik.slotshaven.it\/wordpress\/wp-json\/wp\/v2\/tags?post=4352"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Github<\/h2>\n\n\n\n
Push og Pull<\/h3>\n\n\n\n
git add --all \/\/ L\u00e6g eventuelle nye filer ind i projektet\ngit commit --all -m\"Jeg har gjort dit og dat\" \/\/ stage\ngit push \/\/ L\u00e6g filerne ud p\u00e5 GitHub<\/pre>\n\n\n\n
Kom i gang<\/h3>\n\n\n\n
Fremgangsm\u00e5de: GitHub Desktop<\/h2>\n\n\n\n
![\"\"](\"https:\/\/digitalteknik.slotshaven.it\/wordpress\/wp-content\/uploads\/2021\/02\/image.png\")
<\/figure><\/div>\n\n\n\n1. Create\/add <\/h2>\n\n\n\n
Git ignore (.gitignore)?<\/h3>\n\n\n\n
Hvad med licens?<\/h3>\n\n\n\n
2. Clone\/Fork<\/h2>\n\n\n\n
Pull request <\/h3>\n\n\n\n
Samarbejde<\/h3>\n\n\n\n
Branches<\/h3>\n\n\n\n
3. Et helt nyt projekt<\/h2>\n\n\n\n
Lidt mere lingo<\/h2>\n\n\n\n