mboost-dp1
Git vs andre VCS
Apropos http://newz.dk/subversion-er-nu-apache-subversion, så er der lavet en mikro undersøgelse hvor Git scorer ret godt:
http://agile.dzone.com/news/vcs-survey
http://agile.dzone.com/news/vcs-survey
Jeg har kun brugt svn. Det er jeg udmærket tilfreds med, det har reddet min røv et par gange. Jeg har dog haft problemer med at en på en windows boks (tror ikke det har noget med OS at gøre) har flyttet en fil ud af svn folderen og derefter commitet det (dvs. slettet det), hvilket ødelagde det helt for mig så jeg ikke kunne committe filen i den mappe (+ unresolved blabla).
Jeg har kun hørt godt om git, så det kan være det skal prøves en dag...
Jeg har kun hørt godt om git, så det kan være det skal prøves en dag...
Jeg er blevet ret glad for git, da den har nogle ret lækre features.
Fx. er det næsten omkostningsfrit at oprette et nyt repository med git.
cd $sti
git init .
git add .
git commit -m "Inititial commit"
Det er ret lækkert, hvis man fx. sidder og skriver en opgave og laver en masse rettelser som man måske hurtigt vil kunne rette tilbage, man skal bare huske at committe ofte.
Vil man så gå til tilbage til et tidligere commit, så slår man lige op i git log og finder det commit man vil tilbage til og bruger dets hash sammen med git checkout <HASH>
Men det er for mig slår svn er hastigheden, på mit mediacenter tager det ca. 1½ time at køre en checkout på xbmc. Hvis jeg bruger git mod deres git-mirror, så tager det ca. 20 min.
Et feature som git-entusiaterne til sslug-møder tippede mig om, er git grep som er langt hurtigere end alm. grep på en linux maskine, da dataen allerede er indexeret.
Det er så hurtigt, at det ofte kan betale sig at smide en masse filer i git og derefter bruge git grep til at søge i dem.
Jeg havde dog ret svært ved at komme i gang med det, gitcasts hjalp mig meget:
http://gitcasts.com
EDIT: Ups forkert URL.
Fx. er det næsten omkostningsfrit at oprette et nyt repository med git.
cd $sti
git init .
git add .
git commit -m "Inititial commit"
Det er ret lækkert, hvis man fx. sidder og skriver en opgave og laver en masse rettelser som man måske hurtigt vil kunne rette tilbage, man skal bare huske at committe ofte.
Vil man så gå til tilbage til et tidligere commit, så slår man lige op i git log og finder det commit man vil tilbage til og bruger dets hash sammen med git checkout <HASH>
Men det er for mig slår svn er hastigheden, på mit mediacenter tager det ca. 1½ time at køre en checkout på xbmc. Hvis jeg bruger git mod deres git-mirror, så tager det ca. 20 min.
Et feature som git-entusiaterne til sslug-møder tippede mig om, er git grep som er langt hurtigere end alm. grep på en linux maskine, da dataen allerede er indexeret.
Det er så hurtigt, at det ofte kan betale sig at smide en masse filer i git og derefter bruge git grep til at søge i dem.
Jeg havde dog ret svært ved at komme i gang med det, gitcasts hjalp mig meget:
http://gitcasts.com
EDIT: Ups forkert URL.
Prøvede at søge på Mercurial vs git og fandt frem til:
http://importantshock.wordpress.com/2008/08/07/git...
Jeg er solgt allerede ved "Git is MacGyver".
http://importantshock.wordpress.com/2008/08/07/git...
Jeg er solgt allerede ved "Git is MacGyver".
Fantastisk artikel :D Men det skal jo så lige siges "Mercurial is James Bond".m_abs (6) skrev:Prøvede at søge på Mercurial vs git og fandt frem til:
http://importantshock.wordpress.com/2008/08/07/git...
Jeg er solgt allerede ved "Git is MacGyver".
Jeg kan også lide dette her:
After switching to Mercurial for a small two-person project last year, my collaborator observed that Mercurial feels a lot more Mac-like – usability and smoothness of operation trump Unix philosophy when necessary. If I don’t have to share my code with anyone, I tend to use Mercurial in order to get things done faster.
Det illustrere også meget mine egne meninger og erfaringer.
En manglende faktor der har betydning er "udbredelse" og "erfarings- og uddannelses-mæssig fragmentering".
Eksempelvis så kunne jeg med stor succes indføre en CLI-baseret Git til en udvalgt gruppe af medarbejdere, med meget teknisk og VSC-erfaring. De vil derefter alle give Git en høj score.
Til "pøblen" derimod, er der indført TortoiseSVN. Der er mange for hvilket VSC er en direkte fornærmelse. (Sådan da.) Og SVN vil derfor ikke få en så god score. Men hvis jeg indførte en CLI-baseret Git til disse, så vil de ikke nøjes med at give en dårlig score. (De vil stå ude foran min dør næste dag, med fakler og høtyve!)
For at undersøgelsen skal give mening, må man derfor gå ud fra at brugerne alle har samme mænge erfaring med VSC og har samme arbejdsvirke.
Eksempelvis så kunne jeg med stor succes indføre en CLI-baseret Git til en udvalgt gruppe af medarbejdere, med meget teknisk og VSC-erfaring. De vil derefter alle give Git en høj score.
Til "pøblen" derimod, er der indført TortoiseSVN. Der er mange for hvilket VSC er en direkte fornærmelse. (Sådan da.) Og SVN vil derfor ikke få en så god score. Men hvis jeg indførte en CLI-baseret Git til disse, så vil de ikke nøjes med at give en dårlig score. (De vil stå ude foran min dør næste dag, med fakler og høtyve!)
For at undersøgelsen skal give mening, må man derfor gå ud fra at brugerne alle har samme mænge erfaring med VSC og har samme arbejdsvirke.
Men nu når vi er ved det, så kunne et relevant spørgsmål være:
Hvad tror I der er det bedste system at indføre som "det første" til "pøblen"? Altså folk der aldrig har hørt om versionskontrol før og hvis primære virke består i at arbejde med eks. Word, Publisher, Turbo-Pascal, Special-program X, whatever.
Jeg har kun haft moderat succes med SVN. Og kun pga. "stifinder" og TortoiseSVN. (Denne type brugere vil forøvrigt næppe kunne se forskel på TortoiseSVN og TortoiseGit.)
Hvad tror I der er det bedste system at indføre som "det første" til "pøblen"? Altså folk der aldrig har hørt om versionskontrol før og hvis primære virke består i at arbejde med eks. Word, Publisher, Turbo-Pascal, Special-program X, whatever.
Jeg har kun haft moderat succes med SVN. Og kun pga. "stifinder" og TortoiseSVN. (Denne type brugere vil forøvrigt næppe kunne se forskel på TortoiseSVN og TortoiseGit.)
Jeg tror faktisk at Mercurial ville være glimrende.illishar (10) skrev:Hvad tror I der er det bedste system at indføre som "det første" til "pøblen"? Altså folk der aldrig har hørt om versionskontrol før og hvis primære virke består i at arbejde med eks. Word, Publisher, Turbo-Pascal, Special-program X, whatever.
Der er også TortoiseHG, hvis man ikke benytter sig af et IDE.
Personligt foretrækker jeg at bruge VCS gennem mit IDE (VS/Eclipse/younameit), og jeg forstår stadigvæk ikke Git folkets had til værktøjer og plugins.
Windcape (12) skrev:Personligt foretrækker jeg at bruge VCS gennem mit IDE (VS/Eclipse/younameit), og jeg forstår stadigvæk ikke Git folkets had til værktøjer og plugins.
Jeg har tilgengæld svært ved at forstå, hvorfor du er så glad for at skære folk over en kam og har så svært ved at acceptere at folk har andre præferencer end dig.
Git er et effektivt værktøj i sig selv, et værktøj som mange open source udviklere er enormt glade for.
Du har nok bare endnu engang forvekslet værktøj med IDE, hvor til jeg bliver nødtil at påpege der er Git plugins til eclipse, den kommende KDevelop4, NetBeans, VS2008, IntelliJ IDEA, Qt Creator osv.
Jeg kan virkelig ikke se, hvordan Git folket skulle hade værktøjer.
#13
De fleste Git IDE plugins er stadigvæk i beta stadiet, og der er altså lang vej endnu i forhold til CVS/SVN/Mercurial/ClearCase/TFS når vi snakker om IDE integration.
Git ligger også meget op til at man er terminalbasher, frem for at integerer det som en del af ens normale udviklingsplatform.
Alle de nævnte VCS er effiktive værktøjer, som mange open OG closed-source udviklere er enormt glade for. Derfor må det vel være relevant at vælge det værktøj som er nemmest at bruge, og integerer bedst med ens udviklingsplatform.
Altså Git er fint, hvis man alligevel bruger størstedelen af sin dag som terminalbasher, og måske koder i Emacs eller vim, frem for større IDE miljøer som Eclipse eller Visual Studio.
Men det ændre ikke på at Gits community altså ikke er synderlig positive over for tanken om GUI og IDE integration.
De fleste Git IDE plugins er stadigvæk i beta stadiet, og der er altså lang vej endnu i forhold til CVS/SVN/Mercurial/ClearCase/TFS når vi snakker om IDE integration.
Git ligger også meget op til at man er terminalbasher, frem for at integerer det som en del af ens normale udviklingsplatform.
Alle de nævnte VCS er effiktive værktøjer, som mange open OG closed-source udviklere er enormt glade for. Derfor må det vel være relevant at vælge det værktøj som er nemmest at bruge, og integerer bedst med ens udviklingsplatform.
Altså Git er fint, hvis man alligevel bruger størstedelen af sin dag som terminalbasher, og måske koder i Emacs eller vim, frem for større IDE miljøer som Eclipse eller Visual Studio.
Men det ændre ikke på at Gits community altså ikke er synderlig positive over for tanken om GUI og IDE integration.
Windcape (14) skrev:Git ligger også meget op til at man er terminalbasher, frem for at integerer det som en del af ens normale udviklingsplatform.
Ikke mere end SVN gør.
Og der er ikke altså ikke noget negativt i at bruge en terminal, hvis man magter det. ;)
Windcape (14) skrev:Alle de nævnte VCS er effiktive værktøjer, som mange open OG closed-source udviklere er enormt glade for. Derfor må det vel være relevant at vælge det værktøj som er nemmest at bruge, og integerer bedst med ens udviklingsplatform.
Ja, det er jeg ikke uenig i. Men det har bare meget lidt at gøre med, hvad du skrev.
Windcape (14) skrev:Altså Git er fint, hvis man alligevel bruger størstedelen af sin dag som terminalbasher, og måske koder i Emacs eller vim, frem for større IDE miljøer som Eclipse eller Visual Studio.
Igen Git ligger ikke mere op til terminal end SVN gør. Du kan bruge tredjeparts GUI værktøjer til begge, hvis det er hvad du ønsker men du kan også bruge det oprindelige værktøjer som er terminal baseret, hvis du ønsker og magter det.
I øvrigt fungere Git integrationen fint i den kommende KDevelop4. Det er et must, hvis de skal have KDE-udviklerne over på den, da KDE snart skifter fra SVN til Git.
Er der en der har prøvet TortoiseGit? Så vidt jeg umildbart skulle den være en rimelig færdig shell-integration til Windows, men da jeg ikke har Windows tilgængelig kan jeg ikke lige teste den. Den har i øvrigt været stabile længere end TortoiseHg har været det ;)
Windcape (14) skrev:Men det ændre ikke på at Gits community altså ikke er synderlig positive over for tanken om GUI og IDE integration.
Det har bare ikke ret meget at gøre med:
...og jeg forstår stadigvæk ikke Git folkets had til værktøjer og plugins.
Men du kom vel til at forveksle værktøjer med IDE. :)
illishar (18) skrev:Hvis Git-folket hader IDE'er (som du antyder i quoten), så lægger de nok heller ikke så mange kræfter i at lave plugins til disse. (Som er det Windcape efterlyser.)
Jeg antyder ikke noget, citatet var fra windcape i #12, hvor han påstår "Git-folket" hader værktøjer, det gør de ikke.
Det kan da godt være windcape fejlagtigt tror at det eneste værktøj til udvikling er en IDE eller tror at hvis man har det bedre med andre værktøjer, så må man nødvendigvis hade IDEer.
Jeg er så også rimelig uenig i, der ikke lægges mange kræfter i git-plugins til IDEer, jeg har allerede liste flere IDEer der er Git-plugins til. Dertil kommer shell-extensionen TortoiseGit som har været stabile længere end TortoiseHg.
#19 TortoiseGit er til gengæld så sindssygt meget crap at alle udviklerne burde straffes.
Jeg synes at TortoiseGit desværre er lavet efter at det skulle ligne tortoiseSVN så meget som muligt, frem for at supportere git's awesomeness.
Jeg er dog heller ikke så stor fan af tortoiseSVN, så jeg nok list biased.
Jeg synes at TortoiseGit desværre er lavet efter at det skulle ligne tortoiseSVN så meget som muligt, frem for at supportere git's awesomeness.
Jeg er dog heller ikke så stor fan af tortoiseSVN, så jeg nok list biased.
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
- ⟨
- Tagwall
Gå til bund