Argumenter for å selge inn Git/DVCS?

[dahuff]

Mens jeg vedlikeholdte ett prosjekt som var i produksjon innså jeg at langtrekkelige feature brancher var veldig vanskelig å arbeide med i Subversion. Løsningen ble å sette meg inn i Git hvor branching/merging er billig. Git på kommandolinje (Bash eller Git Shell alt etter plattform som er tilgjengelig) med vim og gitk er alt jeg behøver for å arbeide effektivt.

 

Nå er situasjonen slik at jeg blir å jobbe mer i team framover med utviklere som bruker Visual Studio og Subversion. Interessen for å lære seg ett nytt versjonskontrollsystem er ikke så stor. Jeg har hørt at GUI verktøyene for Subversion er hakket mer modne enn de for Git.

 

Er det noen gode argumenter som jeg kan bruke for å overtale de andre på teamet til å se nytten i å ta i bruk Git? Det er vanskelig å nå igjennom med argumentene mine når noen av de andre ikke har hatt behov for å lage brancher eller å jobbe desentralisert. Skulle derfor gjerne hatt noen flere synspunkter, vinklinger eller erfaringer om det å innføre Git i ett team. Takk.

Endret 19. oktober 2012 av dahuff

[GeirGrusom]

På teamet jeg er på nå benyttes Team Foundation. Dette har i utgangspunktet støtte for branching, men vi benytter det ikke. Ulempene med det er at når arbeidsoppgaver skal deployes, så er kanskje ikke alle ferdige enda. Med en branch så er det bare rett og slett ikke en del av repositoryet før det blir merget. Dersom man ikke gjør det, så kan det lett skje at ting som kanskje ikke burde vært i produksjon havner der, eller ting som burde vært i produksjon ikke havner der (som vel er mer vanlig)

Enklere å holde oversikt.

Det er også enklere å jobbe med flere oppgaver samtidig uten at du blander oppgaver sammen, ettersom du kan comitte uten å pushe endringer. Dette kan også gjøres uten å ha kontakt med serveren, og ettersom alle personer har en kopi av hele repository, så får man også ekstra redundans.

 

Jeg har derimot enda ikke vært på en arbeidsplass hvor det benyttes Git eller Mercurial. Det har hittil vært Subversion eller Team Foundation, men alle snakker om å migrere hele tiden, men det skjer aldri noe. Ganske irriterende.

 

edit: Git verktøyene til Visual Studio er blitt veldig mye bedre i det siste, sikkert i takt med at folk faktisk begynner å bruke det.

Endret 20. oktober 2012 av GeirGrusom

[tomsi42]

Vi bruker Mercurial som gir deg fordelen med gode GUI verktøy på Windows (som Subversion) men er distribuert (som git).

 

Vi brukte Perforce før (som kan sammenlignes med Subversion i bruk), og ingen ønsker seg tilbake. Dvs. vi har også brukt Subversion på noen prosjekter; men det var før vi gikk over til mercurial.

[dahuff]

På teamet jeg er på nå benyttes Team Foundation. Dette har i utgangspunktet støtte for branching, men vi benytter det ikke. Ulempene med det er at når arbeidsoppgaver skal deployes, så er kanskje ikke alle ferdige enda. Med en branch så er det bare rett og slett ikke en del av repositoryet før det blir merget. Dersom man ikke gjør det, så kan det lett skje at ting som kanskje ikke burde vært i produksjon havner der, eller ting som burde vært i produksjon ikke havner der (som vel er mer vanlig)

Enklere å holde oversikt.

Det er også enklere å jobbe med flere oppgaver samtidig uten at du blander oppgaver sammen, ettersom du kan comitte uten å pushe endringer. Dette kan også gjøres uten å ha kontakt med serveren, og ettersom alle personer har en kopi av hele repository, så får man også ekstra redundans.

 

Jeg har derimot enda ikke vært på en arbeidsplass hvor det benyttes Git eller Mercurial. Det har hittil vært Subversion eller Team Foundation, men alle snakker om å migrere hele tiden, men det skjer aldri noe. Ganske irriterende.

 

edit: Git verktøyene til Visual Studio er blitt veldig mye bedre i det siste, sikkert i takt med at folk faktisk begynner å bruke det.

Er det noen spesielle plugins for VS du ser peker seg ut?

 

PS: Det finnes nå en Git plugin for TF. Git-tf ser veldig likt ut som å jobbe med git-svn. Dog, man er delvis bundet til den arbeidsflyten tf/svn tilbyr når man bruker git som en klient.

Vi bruker Mercurial som gir deg fordelen med gode GUI verktøy på Windows (som Subversion) men er distribuert (som git).

 

Vi brukte Perforce før (som kan sammenlignes med Subversion i bruk), og ingen ønsker seg tilbake. Dvs. vi har også brukt Subversion på noen prosjekter; men det var før vi gikk over til mercurial.

 

Hvordan var det å overtale teamet til å bytte ut Perforce? Det må ha vært blandede reaksjoner om det kan jeg tro.

[tomsi42]

Hvordan var det å overtale teamet til å bytte ut Perforce? Det må ha vært blandede reaksjoner om det kan jeg tro.

Det som faktisk skjedde, var at vi ble kjøpt opp av et finsk firma som brukte ClearCase. I løpet av 2008 så ble vi nødt til å kutte ut Perforce og gå over til ClearCase - og det førte til meget dårlig stemning. Det som var interessant, var at det var samtidig et opprør mot CC i Finland ... og avdeling i England brukte Subversion, og nektet å ta i CC.

 

Enden på visa var at det ble satt opp en gruppe for å finne ut hva man skulle bruke istedet og man endte opp med Mercurial. Mye av grunnen var at det da ikke fantes gode nok verktøy for git på Windows den gangen. Og vi støtter mange platformer (Windows, HP-UX, AIX, Solaris, Linux) så Windows-spesifikke verktøy var ikke et alternativ.

 

Vi klarte faktisk å importere all historikk fra Perforce og CC inn i Mercurial. Så vi har et kodetre med historikk tilbake til tidlig 2000-tallet. Tror ikke det er noen som savner Perforce i dag.

Endret 20. oktober 2012 av tomsi42

[zotbar1234]

Nå er situasjonen slik at jeg blir å jobbe mer i team framover med utviklere som bruker Visual Studio og Subversion. Interessen for å lære seg ett nytt versjonskontrollsystem er ikke så stor.

 

Jeg har veldig lyst til å henvise til

(selv om utsagnet er om cvs, er det likefullt brukbart om svn), men det blir kanskje litt vel lite konstruktivt.

 

Er det noen gode argumenter som jeg kan bruke for å overtale de andre på teamet til å se nytten i å ta i bruk Git?

 

* The GIT parable er veldig fin, hvor høyst reelle problemstillinger leder til en naturlig mengde med løsninger.

* Spørsmålet er ikke akkurat nytt og det finnes flere svar på dette spørsmålet.

 

For min egen del liker jeg veldig godt hvor enkelt eksperimentene kan gjøres i en branch uten at noen andre blir affisert, at endringene man har i luften kan legges til side med stash, at man slipper å måtte ha en forbindelse med master repository for å gjøre en rekke operasjoner (slik som blame), at man kan gjøre en rekke små (men komplette skritt) med commits for seg selv og deretter reorganisere ting (rebase -i) før man "offentliggjør" endringene i et offisielt repo. Jeg liker spesielt at man kan etterjustere en commit, når man innser at man har glemt noe (før man har gjort en push; et typisk scenario for meg er å innse at jeg har glemt en filleting som forårsaker at en av testene feiler og da blir det en rekke --amend).

 

Det er en rekke flere operasjoner som jeg har personlig ikke mestret ennå (git grep, git merge-base, f.eks), og der er det også en rekke svært nyttige tricks.

 

Det må egentlig ikke være git spesifikt (hg er blitt nevnt alt), men svn er veldig ødelagt på mange måter.

 

Det er vanskelig å nå igjennom med argumentene mine når noen av de andre ikke har hatt behov for å lage brancher eller å jobbe desentralisert.

 

Det er vanskelig å fortelle en person som har aldri måttet frakte store ting at traller er nyttige. Har man et sett med verktøy som ikke tillater branching på en enkel måte, blir det vanskelig å selge branching som et nyttig verktøy.

[dahuff]

Er veldig enig i de tekniske argumentene du nevner zotbar. Det var også derfor jeg hadde Git på gjøremålslisten, og behøvde bare ett lite dytt for å ta det inn i full skala for min egen del.

 

[...]

Det er vanskelig å nå igjennom med argumentene mine når noen av de andre ikke har hatt behov for å lage brancher eller å jobbe desentralisert.

 

Det er vanskelig å fortelle en person som har aldri måttet frakte store ting at traller er nyttige. Har man et sett med verktøy som ikke tillater branching på en enkel måte, blir det vanskelig å selge branching som et nyttig verktøy.

 

Det er dette det koker ned til, de tekniske argumentene finnes det mange av, men når dette ikke holder må man bare endre strategi. Jeg lurer på om det er bedre å fokusere på arbeidsflyt. Med Subversion er man ganske låst til framatgåenderevisjoner, en sentral trunk og tett dialog mellom utviklerne. Med Git kan man arbeide i sin egen sandkasse og kan dele kode når man føler at man har løst feature request NN. Eller man kan dytte feature branch til felles server og involvere en annen utvikler uten å gjøre alt i trunk. Mulighetene er mange og nesten overveldende, men kanskje også litt vanskelig å selge inn inntil man kan peke på at Git (DVCS) løser ett bestemt problem for teamet.

[vebbiii]

Er veldig enig i de tekniske argumentene du nevner zotbar. Det var også derfor jeg hadde Git på gjøremålslisten, og behøvde bare ett lite dytt for å ta det inn i full skala for min egen del.

 

 

 

Det er dette det koker ned til, de tekniske argumentene finnes det mange av, men når dette ikke holder må man bare endre strategi. Jeg lurer på om det er bedre å fokusere på arbeidsflyt. Med Subversion er man ganske låst til framatgåenderevisjoner, en sentral trunk og tett dialog mellom utviklerne. Med Git kan man arbeide i sin egen sandkasse og kan dele kode når man føler at man har løst feature request NN. Eller man kan dytte feature branch til felles server og involvere en annen utvikler uten å gjøre alt i trunk. Mulighetene er mange og nesten overveldende, men kanskje også litt vanskelig å selge inn inntil man kan peke på at Git (DVCS) løser ett bestemt problem for teamet.

 

Enig i mye av det du sier. Etter å ha migrert fra SVN til git oppstod det noen problemer for oss i begynnelsen, men når vi først fikk en skikkelig flyt på det, ser jeg helt klart mulighetene med git. Dog, uansett hva man migrerer fra og til, så vil det nok alltid oppstå noen problemer i begynnelsen, så det må dere ta høyde for.

 

Forresten, så bruker vi ikke Git bash, men i stedet EGit, som er en plugin til eclipse.