mboost-dp1
Git
#1 Ideen med Github er jo, at dit public repository er tilgængeligt for alle så folk altid kan downloade dine releases og forskellige versioner af din kode. Derudover kan folk lave patches til din kode og lave et såkaldt "Pull request" (et request for, at du puller deres patches ind i din kodebase og bliver en del af det primære repo).
Dét kan man jo ikke med et repository på sin lokale maskine, med mindre man selv gider sætte webfjæs op og har en server kørende derhjemme :)
Det fede ved et distribueret versioneringssystem er, at du ikke skal sætte en server op for at kunne versionere din kode.
Tidl. måtte en udvikler jo sætte f.eks. en Subversion server op, oprette repository/ies, oprette bruger/e osv førend han/hun kunne gå i gang med at 'comitte' til repo'et. Det slipper man for med Git.
Dét kan man jo ikke med et repository på sin lokale maskine, med mindre man selv gider sætte webfjæs op og har en server kørende derhjemme :)
Det fede ved et distribueret versioneringssystem er, at du ikke skal sætte en server op for at kunne versionere din kode.
Tidl. måtte en udvikler jo sætte f.eks. en Subversion server op, oprette repository/ies, oprette bruger/e osv førend han/hun kunne gå i gang med at 'comitte' til repo'et. Det slipper man for med Git.
Men decentraliseringen giver vel i praksis ikke rigtig mening? For hvis man skal kunne udvikle, er man jo nød til at have et fælles sted at spørge efter den seneste version, ellers bliver det da for alvor noget rod. Den eneste fordel jeg kan se er, at det ikke kræver en dedikeret server som #2 nævner, og derfor kan bruges i et single computer setup.
En af de store fordele ved Git er at man kan "committe" lokalt til sit eget repository, før man er klar til at dele sine ændringer med serveren. På den måde har man stadig mulighed for at lave en stor undo operation hvis man fortryder nogle ændringer, uden nødvendigvis at skulle reverte helt tilbage til sidste officielle revision.
#3: Ja, decentraliseringen er ikke en opfordring til at afskaffe sin centrale server. I open source projekter bliver det til gengæld lettere at lave branches af et projekt og siden merge dem sammen igen, da branchen ikke behøver findes i samme repository som trunk. Prøv fx at se på https://github.com/joyent/node/network (scroll lidt til venstre for at se nogle forks og merges).
#3: Ja, decentraliseringen er ikke en opfordring til at afskaffe sin centrale server. I open source projekter bliver det til gengæld lettere at lave branches af et projekt og siden merge dem sammen igen, da branchen ikke behøver findes i samme repository som trunk. Prøv fx at se på https://github.com/joyent/node/network (scroll lidt til venstre for at se nogle forks og merges).
Det er ikke nødvendigt. Der er en række personer som hver har en gren med deres seneste version. Så kan de hente ændringer fra hinanden og merge dem ind i deres gren.Kelrond (3) skrev:For hvis man skal kunne udvikle, er man jo nød til at have et fælles sted at spørge efter den seneste version
De fleste anser stadig Linus gren som værende den officielle og vil periodisk hente opdateringer derfra og prøve at få deres egne opdateringer med i den gren.
De fleste brugere får deres kerne fra en af de mange distributioner. Når man laver en ny version af en distribution gør man som regel følgende:
- Tag den nyeste stable release af Linus version
- Tilføj patches med features som man gerne vil have med selvom Linus ikke synes de er helt klar
- Tilføj patches med bugfixes indtil man er tilfreds.
Efter git blev introduceret og metoden med bugfix releases på kernel.org blev introduceret burde mængden af patches distributionerne har brug for være gået ned. Jeg har ikke undersøgt om det også i praksis forholder sig sådan.
Det fede ved decentraliserede versions styrings systemer som Git er at man ikke er afhængig af at en central server er oppe at køre.
Men jeg vil tro at større teams vil have en central server med et repository som er en slags "main" branch og integrations serveren kan lytte på for ændringer.
Men jeg vil tro at større teams vil have en central server med et repository som er en slags "main" branch og integrations serveren kan lytte på for ændringer.
Asger.F (4) skrev:En af de store fordele ved Git er at man kan "committe" lokalt til sit eget repository, før man er klar til at dele sine ændringer med serveren. På den måde har man stadig mulighed for at lave en stor undo operation hvis man fortryder nogle ændringer, uden nødvendigvis at skulle reverte helt tilbage til sidste officielle revision.
Det klarer man ret enkelt i SVN ved at lave en branch.
#7
Git gør det anderledes, da man under SVN er nødt til at dele sin branch med sine arbejdskollegaer på serveren og branching er hermed stadig lidt en speciel begivenhed under SVN.
Når man brancher lokalt med Git, behøver man ikke at dele sine private branches med nogen, og man er fri for spørgsmål om, hvorvidt man skal bruge en branch eller ej.
Iøvrigt er Git styrtende hurtig til at lave og håndtere branches ifht. SVN.
Dermed er man opmuntret til tit og ofte at lave branches lokalt, hvis man skal lave og teste større ændringer. Når man er færdig med sit arbejde, merger man sine branches ind i sin canonical branch (Master, f.eks) og pusher den til sit public repository, f.eks. Github og nedlægger de private branches, man ikke længere har brug for.
Derfor er det heller ikke unormalt at sidde med 5-10 forskellige private branches i Git.
Git gør det anderledes, da man under SVN er nødt til at dele sin branch med sine arbejdskollegaer på serveren og branching er hermed stadig lidt en speciel begivenhed under SVN.
Når man brancher lokalt med Git, behøver man ikke at dele sine private branches med nogen, og man er fri for spørgsmål om, hvorvidt man skal bruge en branch eller ej.
Iøvrigt er Git styrtende hurtig til at lave og håndtere branches ifht. SVN.
Dermed er man opmuntret til tit og ofte at lave branches lokalt, hvis man skal lave og teste større ændringer. Når man er færdig med sit arbejde, merger man sine branches ind i sin canonical branch (Master, f.eks) og pusher den til sit public repository, f.eks. Github og nedlægger de private branches, man ikke længere har brug for.
Derfor er det heller ikke unormalt at sidde med 5-10 forskellige private branches i Git.
tbdaugaard (2) skrev:Tidl. måtte en udvikler jo sætte f.eks. en Subversion server op, oprette repository/ies, oprette bruger/e osv førend han/hun kunne gå i gang med at 'comitte' til repo'et. Det slipper man for med Git.
???
SVN kræver en server.
GIT kræver en server.
Man kan bruge en public eller sin egen SVN server.
Man kan bruge en public eller sin egen GIT server.
Jeg har lidt svært ved at se tidsbesparelsen.
Men det er godt der stadigvæk er Mercurial, til os som faktisk bruger Windows :p
Desuden så er Git populært pga. hype, og det socialt-netværke omkring Github. Ikke så meget pga. funktionalitet.
Mercurial kan stort set det samme, men fungerer er meget bedre på Windows. Git er designet til Linux, hvor Mercurial er designet cross-platform.
(Og Mercurial er skrevet i Python, Git i C)
Desuden så er Git populært pga. hype, og det socialt-netværke omkring Github. Ikke så meget pga. funktionalitet.
Mercurial kan stort set det samme, men fungerer er meget bedre på Windows. Git er designet til Linux, hvor Mercurial er designet cross-platform.
(Og Mercurial er skrevet i Python, Git i C)
Nej. DVCS kræver ikke nogen server for at komme i gang. Du kan lave et lokalt repo, hvor du commiter til, lang lang tid før du opretter et central repo.arne_v (10) skrev:GIT kræver en server.
> hg init
> hg addremove
> hg commit -m "Initial Commit"
10 hours later
> hg push reponame
SVN kræver at du har et centralt repo fra sekund ét.
Og hele fordelen ved at kunne comitte lokalt, er altså at du kan lave et commit for hver enkelt rettelse.
Dermed får du en commit-log der viser præcist hvad der er blevet ændret, og det gør merges uendeligt meget nemmere.
Hvor folk med SVN måske comitter centralt et par gange om dagen, vil en Git/Mercurial bruger gøre det flere gange i timen.
Dermed får du en commit-log der viser præcist hvad der er blevet ændret, og det gør merges uendeligt meget nemmere.
Hvor folk med SVN måske comitter centralt et par gange om dagen, vil en Git/Mercurial bruger gøre det flere gange i timen.
#11
Hvordan er Windows supporten dårlig? Er det fordi der mangler GUI/IDE-integration? Jeg har altid brugt commandline til git, det fungerer udmærket. SVN er tilgengæld ubehageligt at arbejde med fra CL.
Hvordan er Windows supporten dårlig? Er det fordi der mangler GUI/IDE-integration? Jeg har altid brugt commandline til git, det fungerer udmærket. SVN er tilgengæld ubehageligt at arbejde med fra CL.
#16
I git er det meget almindeligt at lave mange commits lokalt for så at lave en rebase for at samle flere commits til en før man committer til et repository.
I git er det meget almindeligt at lave mange commits lokalt for så at lave en rebase for at samle flere commits til en før man committer til et repository.
Nogle gange arbejder man nu engang offline. Med flere af systemerne kan man ikke commite uden forbindelse til serveren.arne_v (16) skrev:Man committer når man har noget der er relevant at committe uanset hvilket VCS man bruger.
Men hvorfor dog? Hvis man senere skal debugge problemer er det en fordel at have opdateringerne i så små increments som muligt. For mig at se giver det kun mening hvis det er fordi man har lavet nogle commits som er decideret forkerte og reverter dem. Men i sådan et tilfælde vil man stadigvæk gerne have alle de gode commits i den endelige revisionshistorie.onetreehell (18) skrev:I git er det meget almindeligt at lave mange commits lokalt for så at lave en rebase for at samle flere commits til en før man committer til et repository.
#20
Har du læst denne post af Shawn O. Pearce om hvorfor cgit er så hurtig?
http://marc.info/?l=git&m=124111702609723&...
Har du læst denne post af Shawn O. Pearce om hvorfor cgit er så hurtig?
http://marc.info/?l=git&m=124111702609723&...
#17
Den relle forskel som jeg ser det er at SVN modellen bygger på en tanke om en central styring af udviklings processen mens GIT modellen bygger på at der foregår udvikling totalt uafhængigt af hinanden, hvor dem der har det centrale repository ikke enganmg ved at der eksisterer et lokalt repository.
GIT modellen passer perfelt til open source projekter. Til et firma er det mere smag og behag hvad man bedt kan lide.
Eksempel: i 2021 er windcape ansat hos MS til at udvikle C# version 17 compileren. Han får at vide præcist hvad der skal laves, det skal checkes ind i et centralt repository, hvor det bliver grundigt checket. Men i hans fritid udvikler han en C# compiler i C som skal integreres i Linux kernen for at undgå user mode kernel mode switches. Han har et lokalt repository at arbejde på. Linus har aldrig hørt om windcape og sandsynligvis bliver koden aldrig merget tilbage.
Den relle forskel som jeg ser det er at SVN modellen bygger på en tanke om en central styring af udviklings processen mens GIT modellen bygger på at der foregår udvikling totalt uafhængigt af hinanden, hvor dem der har det centrale repository ikke enganmg ved at der eksisterer et lokalt repository.
GIT modellen passer perfelt til open source projekter. Til et firma er det mere smag og behag hvad man bedt kan lide.
Eksempel: i 2021 er windcape ansat hos MS til at udvikle C# version 17 compileren. Han får at vide præcist hvad der skal laves, det skal checkes ind i et centralt repository, hvor det bliver grundigt checket. Men i hans fritid udvikler han en C# compiler i C som skal integreres i Linux kernen for at undgå user mode kernel mode switches. Han har et lokalt repository at arbejde på. Linus har aldrig hørt om windcape og sandsynligvis bliver koden aldrig merget tilbage.
#23
Det er ikke nødvendigt at se det som central styring. Den reele forskel i dagligdagen er at du kan lave commits for hver rettelse på hvad du arbejder med, og så måske lave et push til frokost, og igen når du har fyraften.
Folk der bruger SVN commiter mere sjældent, fordi at det tager så lang tid at committe.
Og forskellen i at lave 100 lokale commits, og 1 push (DVCS), eller 100 remote commits (CVCS) handler kun om hvor meget tid udviklerne skal spilde på at vente på deres versionstyringsværktøj!
At det så er uendeligt meget nemmere at branche og merge med Git og Mercurial, er noget helt andet. Det er fordi at værktøjerne er af en højere kvalitet en SVN.
Desuden skal du jo tage det med, at ikke alle udviklere i en virksomhed nødvendigvis har lov til at commite/pushe til visse repo's.
Ved at kunne commite lokalt, kan du stadigvæk have versionsstyring, selvom du ikke må pushe (direkte) til test/prod miljøet.
Og så giver det også en mulighed for at have lokal versionsstyring, i virksomheder der ikke benytter versionstyring (som desværre er meget typisk for Danmark!)
Det er ikke nødvendigt at se det som central styring. Den reele forskel i dagligdagen er at du kan lave commits for hver rettelse på hvad du arbejder med, og så måske lave et push til frokost, og igen når du har fyraften.
Folk der bruger SVN commiter mere sjældent, fordi at det tager så lang tid at committe.
Og forskellen i at lave 100 lokale commits, og 1 push (DVCS), eller 100 remote commits (CVCS) handler kun om hvor meget tid udviklerne skal spilde på at vente på deres versionstyringsværktøj!
At det så er uendeligt meget nemmere at branche og merge med Git og Mercurial, er noget helt andet. Det er fordi at værktøjerne er af en højere kvalitet en SVN.
Desuden skal du jo tage det med, at ikke alle udviklere i en virksomhed nødvendigvis har lov til at commite/pushe til visse repo's.
Ved at kunne commite lokalt, kan du stadigvæk have versionsstyring, selvom du ikke må pushe (direkte) til test/prod miljøet.
Og så giver det også en mulighed for at have lokal versionsstyring, i virksomheder der ikke benytter versionstyring (som desværre er meget typisk for Danmark!)
#19
Du kan have lavet stavefejl eller lignende, og det kan være at du i en periode havde committet dårlig kode. Den periode vil bare være støj når du leder efter fejl. Prøv evt. at søge efter hvad Linus Torvalds har at sige om commits og git bisect. Derudover kan det være en fordel at skære en patch ned til meningsfulde commits. Der er tonsvis af gode grunde til at bruge rebase, selvom der selvfølgelig er mange tilfælde hvor det ikke er en god ide. Prøv evt. at læse om "git rebase" f. eks.
Jeg har ikke erfaring med at lave forks med Subversion, men i git er det let at holde en fork hvor man puller updates fra upstream. Der er det jo bare ligesom enhver anden branch man merger med.
Du kan have lavet stavefejl eller lignende, og det kan være at du i en periode havde committet dårlig kode. Den periode vil bare være støj når du leder efter fejl. Prøv evt. at søge efter hvad Linus Torvalds har at sige om commits og git bisect. Derudover kan det være en fordel at skære en patch ned til meningsfulde commits. Der er tonsvis af gode grunde til at bruge rebase, selvom der selvfølgelig er mange tilfælde hvor det ikke er en god ide. Prøv evt. at læse om "git rebase" f. eks.
Jeg har ikke erfaring med at lave forks med Subversion, men i git er det let at holde en fork hvor man puller updates fra upstream. Der er det jo bare ligesom enhver anden branch man merger med.
Ang. central styring: det er altså hverken svært eller besværligt at lave en lokal SVN repository.
Ang. hastighed: Jeg oplever nu ikke SVN værende specielt langsomt. Derudover bør man heller ikke partout commite hver gang du har rettelse, men når du har en meningsfuld, logisk samling rettelser i passende størrelse at committe.
Ang. hastighed: Jeg oplever nu ikke SVN værende specielt langsomt. Derudover bør man heller ikke partout commite hver gang du har rettelse, men når du har en meningsfuld, logisk samling rettelser i passende størrelse at committe.
Nej!Spiderboy (26) skrev:Derudover bør man heller ikke partout commite hver gang du har rettelse, men når du har en meningsfuld, logisk samling rettelser i passende størrelse at committe.
Du skal netop committe hver eneste gang du har lavet en rettelse. 2-3 gange i timen er meget realistisk. Hvor tit henter du kaffe?
Ja, Du skal bruge .gitignore.Spiderboy (27) skrev:Kan man sætte Git til at ignorere bestemte filer/mapper analogt til SVN-egenskaben svn:ignore?
Og til modsætning fra SVN, er det en fil som følger repo'et, og dermed skal hver enkelt bruger ikke selv sætte svn:ignore op.
At svn:ignore stadigvæk skal opsættes på hver enkelt maskine, er så dybt latterligt som det kan blive.
Windcape (28) skrev:Du skal netop committe hver eneste gang du har lavet en rettelse. 2-3 gange i timen er meget realistisk. Hvor tit henter du kaffe?
Jeg tror ikke vi deler opfattelse af hvad en rettelse er. :-)
Med rettelse mente jeg at du f.eks. har været inde og pille ved ved 3 linjer kode e.l.
Jeg er enig i, at 2-3 gange i timen nok er passende.
Windcape (29) skrev:At svn:ignore stadigvæk skal opsættes på hver enkelt maskine, er så dybt latterligt som det kan blive.
Hvorfor? Jeg synes det er fint, at folk selv vælger hvad de vil ignorere i hvert deres checkout.
Folk kunne da godt have forskellige setups, som genererer forskellige midlertidige filer.
Checkouts? Vi snakker om check-ins!Spiderboy (30) skrev:Jeg synes det er fint, at folk selv vælger hvad de vil ignorere i hvert deres checkout.
F.eks. ser min .hgignore (Mercurial, men Git is same same), sådan her ud:
syntax: glob
*.suo
*.user
*.sdf
*.opensdf
*.docstates
syntax: regexp
.git
bin/
Bin/
obj/
TestResults/
TDD/
obj/
Release/
Debug/
Packages/
packages/
ipch/
Det sikre at ingen binære pakker overhovedet bliver checket ind. Kun kode. Dependencies bliver auto-resolved med NuGet.
Windcape (24) skrev:Folk der bruger SVN commiter mere sjældent, fordi at det tager så lang tid at committe.
Windcape (24) skrev:Og forskellen i at lave 100 lokale commits, og 1 push (DVCS), eller 100 remote commits (CVCS) handler kun om hvor meget tid udviklerne skal spilde på at vente på deres versionstyringsværktøj!
Mystisk - jeg har aldrig oplevet commit tid som et problem.
Kan du give nogle referencer til nogen som er glade for CVS/SVN/PVCS/P4 som nævner det som et problem?
Commiter du tit nok så? Committer du hver gang du rejser dig op, henter kaffe, eller tabber over i en browser for at læse nyheder eller mails?arne_v (34) skrev:Mystisk - jeg har aldrig oplevet commit tid som et problem.
Jeg kan kun give dig alle dem som er skiftet til Git og Mercurial netop pga. hastigheden.arne_v (34) skrev:Kan du give nogle referencer til nogen som er glade for CVS/SVN/PVCS/P4 som nævner det som et problem?
SVN commits er langsomme, selv på en lokal server.
(Og noget helt andet, så er det et mareridt at SVN ikke benytter et shallow tree, men i stedet har en .svn mappe i samtlige mapper. Bare endnu en grund til at hade SVN)
Windcape (24) skrev:
Desuden skal du jo tage det med, at ikke alle udviklere i en virksomhed nødvendigvis har lov til at commite/pushe til visse repo's.
Ved at kunne commite lokalt, kan du stadigvæk have versionsstyring, selvom du ikke må pushe (direkte) til test/prod miljøet.
Deployment til test/prod sker efter build - commit sker før build.
Og hvis nogen har forskellige repositories til dev/test/prod, så har de helt misforstået source control.
Hvis udviklere ikke har adgang til at committe i et repository, så er det med stor sandsynlighed fordi de ikke hverken skal eller må rette i den kode.
At de har mulighed for at køre i et uofficielt repository lyder ikke som noget firmaet er interesseret i.
Windcape (35) skrev:Commiter du tit nok så?
Jeg comitter hver gang der er en logisk enhed af arbejde.
Windcape (35) skrev:Committer du hver gang du rejser dig op, henter kaffe, eller tabber over i en browser for at læse nyheder eller mails?
Nej.
Det bruger jeg "Save all" i IDE/editor til.
Der er ingen garanti for at afbrydelser sker midt imellem logiske enheder af arbejde.
Der er garenti for at du har svært ved at huske præcist hvilke ændringer du har lavet, efter en afbrydelse.arne_v (38) skrev:Der er ingen garanti for at afbrydelser sker midt imellem logiske enheder af arbejde.
Commits skal dokumentere ændringer i koden. Ikke ændringer i logikken!
Jeg er uenig. Du kan sagtens have et repository eller branch med kode der er flyttet i test/frys eller som experimental.arne_v (36) skrev:Og hvis nogen har forskellige repositories til dev/test/prod, så har de helt misforstået source control.
Og så er det jo netop en fordel at hvis man alligevel vil lave en patch, at man så kan pull repo'et, skrive en patch, og committe den. Så har man en præcis changelog over hvad der er blevet ændret.arne_v (36) skrev:Hvis udviklere ikke har adgang til at committe i et repository, så er det med stor sandsynlighed fordi de ikke hverken skal eller må rette i den kode.
Hvis man kører med DVCS er har alle udviklerer jo et uofficielt repo.arne_v (36) skrev:At de har mulighed for at køre i et uofficielt repository lyder ikke som noget firmaet er interesseret i.
Der handler i bund og grund om måden man arbejder med koden på. Ligesom agile udviklingsmetoder versus vandfald.
Her er Git/Hg så bare det agile, og SVN er vandfald.
Windcape (39) skrev:Der er garenti for at du har svært ved at huske præcist hvilke ændringer du har lavet, efter en afbrydelse.
Nu har SVN altså mulighed for at vise ændringer lavet i forhold til SVN.
Det tror jeg faktisk også at Git og Hg har.
Umiddelbart virker det lidt mere praktisk end at committe og skrive en kommentar.
Windcape (40) skrev:
Jeg er uenig. Du kan sagtens have et repository eller branch med kode der er flyttet i test/frys eller som experimental.
Du har version N i en given repo/branch kontekst som skifter status "klar til build" -> "klar til test" -> "i test" -> "færdigtestet" -> "accepteret af kunden" -> "i produktion".
Således at man ved at hvad der er testet er det som går i produktion og det som er i version N i en given repo/branch er det som er i produktion.
Hvis man flytter rundt med koden og laver en ny build, så ved man ikke ikke med sikkerhed om det testede er det som går i produktion.
Hvis man flytter rundt men bibeholder den original build, så ved man ikke med sikkerhed om det som er i version N i en given repo/branch er det som er i produktion.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund