git - Waarom is git beter dan subversie?

Ik gebruik subversion voor een paar jaar en na het gebruik van SourceSafe , ik hou gewoon van subversie. Gecombineerd met TortoiseSvn , kan ik me niet echt voorstellen hoe het beter kan zijn.

Toch is er een groeiend aantal ontwikkelaars dat beweert dat subversie problemen heeft en dat we moeten verhuizen naar het nieuwe ras gedistribueerde versiesystemen, zoals Git .

Hoe verbetert git op subversie?

Antwoord 1, Autoriteit 100%

Git is niet beter dan subversie. Maar is ook niet erger. Het is anders.

Het sleutelverschil is dat het gedecentraliseerd is. Stel je voor dat je een ontwikkelaar op de weg bent, je ontwikkelt zich op je laptop en je wilt bronbesturing hebben, zodat je 3 uur terug kunt.

Met Subversion heeft u een probleem: de SVN-repository kan op een locatie staan die u niet kunt bereiken (in uw bedrijf, en u hebt op dit moment niet internet), u kunt u niet plegen. Als u een kopie van uw code wilt maken, moet u het letterlijk kopiëren / plakken.

Met git heeft u dit probleem niet. Uw lokale kopie is een repository en u kunt eraan verbinden en alle voordelen van broncontrole krijgen. Wanneer u de connectiviteit op de hoofdrepository herwint, kunt u zich ertoe verbinden.

Dit ziet er in het begin goed uit, maar houd er gewoon rekening mee met de toegevoegde complexiteit aan deze aanpak.

Git lijkt het “nieuwe, glanzende, coole” ding te zijn. Het is absoluut niet slecht (er is een reden waarom Linus het tenslotte schreef voor de Linux-kernel-ontwikkeling), maar ik voel dat veel mensen springen op de trein “gedistribueerde broncontrole”, alleen maar omdat het nieuw is en wordt geschreven door Linus Torvalds, zonder eigenlijk Weten waarom / als het beter is.

Subversion heeft problemen, maar ook Git, Mercurial, CVS, TFS of wat dan ook.

bewerken: Dus dit antwoord is nu een jaar oud en genereert nog steeds veel upvotes, dus ik dacht dat ik wat meer uitleg voeg. In het afgelopen jaar sinds het schrijven heeft Git veel momentum en ondersteuning gekregen, vooral omdat sites zoals Github echt van start gaan. Ik gebruik tegenwoordig zowel Git als Subversion en ik zou graag wat persoonlijk inzicht willen delen.

Allereerst kan Git aanvankelijk echt verwarrend zijn bij het werken gedecentraliseerd. Wat is een afstandsbediening? En hoe de eerste repository correct in te stellen? zijn twee vragen die in het begin opkomen, vooral in vergelijking met SVN’s simple “Svnadmin Create”, Git’s “Git Init” kan de parameters – bedienen en – van de ‘juiste’ manier om een gecentraliseerde manier te zijn die een gecentraliseerde “manier lijkt te zijn opslagplaats. Er zijn hiervoor redenen, maar voegt complexiteit toe. De documentatie van de opdracht “Checkout” is zeer verwarrend voor mensen die oververwisselen – de “juiste” manier lijkt “Git Clone” te zijn, terwijl “Git Checkout” de takken schakelt.

Git schijnt echt als je gedecentraliseerd bent. Ik heb thuis een server en een laptop op de weg, en SVN werkt hier gewoon niet goed. Met SVN kan ik geen lokale broncontrole hebben als ik niet met de repository ben (ja, ik weet het over SVK of over manieren om de repo te kopiëren). Met Git is dat hoe dan ook de standaardmodus. Het is echter een extra opdracht (Git CIT-commits lokaal, terwijl Git Push Oorsprong Master de Master Branch duwt naar de afgelegen “Origin”).

Zoals hierboven gezegd: Git voegt complexiteit toe. Twee manieren om repositories te creëren, checkout vs. clone, commit vs. push… Je moet weten welke commando’s lokaal werken en welke werken met “de server” (ik neem aan dat de meeste mensen nog steeds van een centrale “master-repository” houden ).

Bovendien is de tooling nog steeds onvoldoende, althans op Windows. Ja, er is een Visual Studio AddIn, maar ik gebruik nog steeds git bash met msysgit.

SVN heeft het voordeel dat het VEEL eenvoudiger te leren is: er is je repository, alle wijzigingen daarin, als je weet hoe je moet maken, vastleggen en afrekenen en je bent klaar om te gaan en dingen als vertakking, update enz. later.

Git heeft het voordeel dat het VEEL beter geschikt is als sommige ontwikkelaars niet altijd verbonden zijn met de hoofdrepository. Het is ook veel sneller dan SVN. En van wat ik hoor, is ondersteuning voor vertakking en samenvoeging een stuk beter (wat te verwachten is, aangezien dit de belangrijkste redenen zijn waarom het is geschreven).

Dit verklaart ook waarom het zoveel buzz op het internet krijgt, aangezien Git perfect geschikt is voor Open Source-projecten: Fork het gewoon, leg je wijzigingen vast in je eigen Fork en vraag dan de oorspronkelijke projectbeheerder om je wijzigingen door te voeren. Met Git werkt dit gewoon. Echt, probeer het op Github, het is magisch.

Wat ik ook zie zijn Git-SVN Bridges: de centrale repository is een Subversion-repo, maar ontwikkelaars werken lokaal met Git en de bridge pusht hun wijzigingen vervolgens naar SVN.

Maar zelfs met deze lange toevoeging blijf ik bij mijn kernboodschap: Git is niet beter of slechter, het is gewoon anders. Als je behoefte hebt aan “Offline Source Control” en de bereidheid hebt om wat extra tijd te besteden aan het leren ervan, dan is dat fantastisch. Maar als je een strikt gecentraliseerd bronbeheer hebt en/of moeite hebt om bronbeheer te introduceren omdat je collega’s niet geïnteresseerd zijn, dan schitteren de eenvoud en uitstekende tooling (althans op Windows) van SVN.

Antwoord 2, autoriteit 26%

Met Git kun je praktisch alles offline doen, omdat iedereen zijn eigen repository heeft.

Vertakkingen maken en samenvoegen tussen takken is heel eenvoudig.

Zelfs als je geen commit-rechten voor een project hebt, kun je nog steeds je eigen repository online hebben en “push-verzoeken” voor je patches publiceren. Iedereen die van je patches houdt, kan ze in hun project opnemen, inclusief de officiële beheerders.

Het is triviaal om een project te forken, het te wijzigen en toch de bugfixes van de HEAD-branch te blijven mergen.

Git werkt voor de Linux-kernelontwikkelaars. Dat betekent dat het heel snel is (het moet wel) en kan worden opgeschaald naar duizenden bijdragers. Git gebruikt ook minder ruimte (tot 30 keer minder ruimte voor de Mozilla-repository).

Git is erg flexibel, erg TIMTOWTDI (er is meer dan één manier om het te doen). Je kunt elke workflow gebruiken die je wilt, en Git zal het ondersteunen.

Eindelijk is er GitHub, een geweldige site voor het hosten van je Git-repositories.

Nadelen van Git:

het is veel moeilijker om te leren, omdat Git meer concepten en meer commando’s heeft.
revisies hebben geen versienummers zoals in subversion
veel Git-commando’s zijn cryptisch en foutmeldingen zijn erg gebruiksonvriendelijk
het mist een goede GUI (zoals de geweldige TortoiseSVN)

Antwoord 3, autoriteit 20%

Andere antwoorden hebben goed werk geleverd door de kernfuncties van Git uit te leggen (die geweldig zijn). Maar er zijn ook zoveel kleinemanieren waarop Git zich beter gedraagt en mijn leven gezonder houdt. Hier zijn enkele van de kleine dingen:

Git heeft een ‘clean’ commando. SVN heeft dit commando hard nodig, gezien hoe vaak het extra bestanden op je schijf zal dumpen.
Git heeft het ‘bisect’-commando. Het is leuk.
SVN maakt .svn-mappen aan in elke afzonderlijke map (Git maakt slechts één.git-map). Elk script dat je schrijft, en elke grep die je doet, moet worden geschreven om deze .svn-directory’s te negeren. Je hebt ook een hele opdracht (“svn export”) nodig om een normale kopie van je bestanden te krijgen.
In SVN kan elk bestand & map kan uit een andere revisie of branch komen. In eerste instantie klinkt het leuk om deze vrijheid te hebben. Maar wat dit eigenlijk betekent, is dat er een miljoen verschillende manieren zijn om uw lokale kassa volledig te verknoeien. (bijvoorbeeld als “svn switch” halverwege mislukt, of als u een verkeerd commando invoert). En het ergste is: als je ooit in een situatie terechtkomt waarin sommige van je bestanden van de ene plaats komen en sommige van de andere, zal de “svn-status” je vertellen dat alles normaal is. Je moet “svn info” op elk bestand/directory doen om te ontdekken hoe raar dingen zijn. Als “git status” je vertelt dat de dingen normaal zijn, dan kun je erop vertrouwen dat de dingen echt normaal zijn.
Je moet SVN vertellen wanneer je iets verplaatst of verwijdert. Git komt er wel achter.
Semantiek negeren is makkelijker in Git. Als u een patroon negeert (zoals *.pyc), wordt het genegeerd voor allesubmappen. (Maar als je echt iets wilt negeren voor slechts één map, dan kan dat). Met SVN lijkt het erop dat er geen gemakkelijke manier is om een patroon in alle submappen te negeren.
Nog een item met negeerbestanden. Git maakt het mogelijk om “private” negeerinstellingen te hebben (met behulp van het bestand .git/info/exclude), die niemand anders zullen beïnvloeden.

Antwoord 4, autoriteit 10%

“Waarom Git beter is dan X” schetst de verschillende voor- en nadelen van Git versus andere SCM’s.

Kort:

Git volgt inhoud in plaats van bestanden
Takken zijn lichtgewichten samenvoegen is eenvoudig, en ik bedoel heel eenvoudig.
Het wordt gedistribueerd, in principe is elke repository een branch. Het is naar mijn mening veel gemakkelijker om gelijktijdig en gezamenlijk te ontwikkelen dan met Subversion. Het maakt ook offlineontwikkeling mogelijk.
Het legt geen enkele workflow uit, zoals te zien is op de hierboven gelinkte website, er zijn veel workflows mogelijk met Git. Een workflow in Subversion-stijl is gemakkelijk na te bootsen.
Git-opslagplaatsen zijn veel kleiner in bestandsgroottedan Subversion-opslagplaatsen. Er is maar één “.git” directory, in tegenstelling tot tientallen “.svn” repositories (let op Subversion 1.7 en hoger gebruikt nu een enkele mapzoals Git.)
Het staging-gebied is geweldig, het stelt je in staat om de wijzigingen te zien die je gaat vastleggen, gedeeltelijke wijzigingen door te voeren en verschillende andere dingen te doen.
Stashing is van onschatbare waarde wanneer u “chaotische” ontwikkeling doet of gewoon een bug wilt oplossen terwijl u nog steeds aan iets anders werkt (op een andere tak).
U kunt Herschrijfgeschiedenis herschrijven , wat geweldig is voor het bereiden van patchsets en het vaststellen van uw fouten (vóór u publiceert de commits)
… en een PARTIJ MEER.

Er zijn enkele nadelen:

Er is nog niet veel goede GUIS voor. Het is nieuw en subversie is al veel langer rond, dus dit is natuurlijk omdat er een paar interfaces in ontwikkeling zijn. Sommige goede zijn omvatten tortoisegit en Github voor Mac .
~~Gedeeltelijke kassa’s / klonen van repositories zijn op dit moment niet mogelijk (ik lees dat het in ontwikkeling is). Er is echter submodule-ondersteuning. Git 1.7+ ondersteunt dunne checkouts .~~
Het is misschien moeilijker om te leren, ook al heb ik dit niet gevonden om het geval (ongeveer een jaar geleden) te zijn. Git heeft onlangs zijn interface verbeterd en is vrij gebruiksvriendelijk.

In het meest simplistische gebruik zijn subversie en git vrijwel hetzelfde. Er is niet veel verschil tussen:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Waar git echt schijnt is vertakkend en werken met andere mensen.

Antwoord 5, Autoriteit 10%

Google Tech Talk: Linus Torvalds op Git

http://www.youtube.com/watch?v=4xpnkhjaok8

De vergelijkingspagina van de git wiki

http://git.or.cz/gitwiki/gitsvncomparion

Antwoord 6, Autoriteit 5%

Nou, het is verdeeld. Benchmarks geven aan dat het aanzienlijk sneller is (gezien zijn gedistribueerde aard, operaties zoals diffs en logboeken zijn allemaal lokaal, dus het is natuurlijk een snellere sneller in dit geval), en werkmappen zijn kleiner (die nog steeds kleiner is).

Wanneer u werkt aan subversie, of een ander klant / server Revision-besturingssysteem, maakt u in wezen werkende kopieën op uw machine door -controle Revisies. Dit vertegenwoordigt een momentopname in de tijd van wat de repository eruit ziet. U werkt uw werkkopie bij via updates en u werkt de repository via commits bij.

Met een gedistribueerde versiebeheer heeft u geen momentopname, maar eerder de volledige codebase. Wil je een diff doen met een versie van 3 maanden? Geen probleem, de 3 maanden oude versie staat nog op uw computer. Dit betekent niet alleen dingen zijn veel sneller, maar als je bent losgekoppeld van je centrale server, kun je nog steeds veel van de operaties doen die je gewend bent. Met andere woorden, u hebt niet alleen een momentopname van een bepaalde revisie, maar de volledige codebase.

Je zou denken dat Git een bos van ruimte op je harde schijf zou opnemen, maar van een paar benchmarks die ik heb gezien, kost het eigenlijk minder. Vraag me niet hoe. Ik bedoel, het werd gebouwd door Linus, hij weet een ding of twee over bestandssystemen die ik denk.

Antwoord 7, Autoriteit 4%

De hoofdpunten die ik leuk vind aan DVC’s zijn die:

Je kunt gebroken dingen plegen. Het maakt niet uit omdat andere mensen ze niet zien totdat je publiceert. Publiceer de tijd is anders van de plattegrond.
Hierdoor kun je vaker committen.
Je kunt volledige functionaliteit samenvoegen. Deze functionaliteit krijgt een eigen branch. Alle commits van deze branch zullen gerelateerd zijn aan deze functionaliteit. Je kunt het doen met een CVCS, maar met DVCS is dit de standaardinstelling.
U kunt uw geschiedenis doorzoeken (vinden wanneer een functie is gewijzigd)
Je kunt een pull ongedaan maken als iemand de hoofdrepository verknoeit, je hoeft de fouten niet te herstellen. Wis de samenvoeging.
Als je een broncode in een map nodig hebt, doe dan : git init . en je kunt committen, wijzigingen ongedaan maken, enz…
Het is snel (zelfs op Windows)

De belangrijkste reden voor een relatief groot project is de verbeterde communicatie die wordt gecreëerd door punt 3. Andere zijn leuke bonussen.

Antwoord 8, autoriteit 3%

Het grappige is:
Ik host projecten in Subversion Repos, maar benader ze via het Git Clone-commando.

Lees Ontwikkelen met Git op een Google Code-project

Hoewel Google Code native spreekt
Subversion, je kunt Git . gemakkelijk gebruiken
tijdens de ontwikkeling. Zoeken naar “git
svn” suggereert dat deze praktijk is
wijdverbreid, en ook wij moedigen u aan
om ermee te experimenteren.

Git gebruiken op een Svn-repository geeft me voordelen:

Ik kan gedistribueerdop meerdere werken
machines, plegen en trekken van
en voor hen
Ik heb een centralebackup/publicsvn-repository die anderen kunnen bekijken
En ze zijn vrij om Git voor zichzelf te gebruiken

Antwoord 9, autoriteit 2%

Alle antwoorden hier zijn zoals verwacht, de programmeur centraal, maar wat gebeurt er als uw bedrijf revisiecontrole gebruikt buiten de broncode? Er zijn tal van documenten die geen broncode zijn en die profiteren van versiebeheer, en die dicht bij de code zouden moeten staan en niet in een ander CMS. De meeste programmeurs werken niet geïsoleerd – we werken voor bedrijven als onderdeel van een team.

Vergelijk daarom het gebruiksgemak, zowel in clienttooling als training, tussen Subversion en git. Ik zie geen scenario waarin eengedistribueerd revisiecontrolesysteem gemakkelijker te gebruiken of uit te leggen zal zijn aan een niet-programmeur. Ik zou graag ongelijk krijgen, want dan zou ik git kunnen evalueren en eigenlijk de hoop hebben dat het wordt geaccepteerd door mensen die versiebeheer nodig hebben en die geen programmeur zijn.

Zelfs dan, als het management ons zou vragen waarom we van een gecentraliseerd naar een gedistribueerd revisiecontrolesysteem zouden moeten overstappen, zou ik moeilijk een eerlijk antwoord kunnen geven, omdat we het niet nodig hebben.

Disclaimer: ik raakte al vroeg geïnteresseerd in Subversion (rond v0.29), dus ik ben duidelijk bevooroordeeld, maar de bedrijven waar ik sinds die tijd voor heb gewerkt, profiteren van mijn enthousiasme omdat ik het gebruik ervan heb aangemoedigd en ondersteund . Ik vermoed dat dit bij de meeste softwarebedrijven zo gaat. Met zoveel programmeurs die op de git-bandwagon springen, vraag ik me af hoeveel bedrijven de voordelen gaan missen van het gebruik van versiebeheer buiten de broncode? Zelfs als u afzonderlijke systemen heeft voor verschillende teams, loopt u een aantal voordelen mis, zoals (geünificeerde) integratie van probleemopsporing, terwijl u de onderhouds-, hardware- en trainingsvereisten verhoogt.

Antwoord 10, autoriteit 2%

Subversion is nog steeds een veel gebruikte versie controle systeem, dat betekent dat het beter instrument te ondersteunen. U zult rijpen SVN plugins te vinden bijna elke IDE , en er zijn goede verkenner extensies ( zoals TurtoiseSVN). Anders dan dat, ik ben het eens met Michael : Git is niet beter of slechter dan Subversion , is het anders.

Antwoord 11

Een van de dingen over SubVersion dat ergert mij is dat het zijn eigen map zet in elke map van een project, terwijl git slechts zet een in de root directory. Het is niet die groot van een deal, maar dat soort dingen optellen.

Natuurlijk SubVersion heeft Tortoise, dat is [meestal] very nice.

Antwoord 12

David Richards WANdisco Blog op Subversion / GIT

De opkomst van GIT heeft bracht een ras van DVCS fundamentalisten – de ‘Gitterons’ – die denken iets anders dan GIT is onzin. De Gitterons schijnen te denken software engineering er gebeurt op hun eigen eiland en vaak vergeten dat de meeste organisaties senior software engineers niet uitsluitend in dienst. Dat is ok, maar het is niet hoe de rest van de markt denkt, en ik ben blij om het te bewijzen: GIT, bij de laatste blik had minder dan drie procent van de markt, terwijl Subversion heeft in het gebied van vijf miljoen gebruikers en ongeveer de helft van de totale markt.

Het probleem dat we zagen was dat de Gitterons (goedkope) schoten afvuurden op Subversion. Tweets als “Subversion is zo [traag/crappy/beperkend/ruikt niet lekker/kijkt me op een grappige manier aan] en nu heb ik GIT en [alles werkt in mijn leven/mijn vrouw werd zwanger/ik kreeg een vriendin na 30 jaar proberen/ik heb zes keer gewonnen op de blackjacktafel]. Je krijgt de foto.

Antwoord 13

Git maakt vertakkingen en samenvoegen ook heel gemakkelijk. Subversion 1.5 heeft zojuist merge-tracking toegevoegd, maar Git is nog steeds beter. Met Git is vertakking erg snel en goedkoop. Het maakt het maken van een vertakking voor elke nieuwe functie haalbaarder. Oh en Git-repositories zijn erg efficiënt met opslagruimte in vergelijking met Subversion.

Antwoord 14

Het draait allemaal om het gebruiksgemak/de stappen die nodig zijn om iets te doen.

Als ik een enkel project op mijn pc/laptop ontwikkel, is git beter, omdat het veel gemakkelijker te installeren en te gebruiken is.
Je hebt geen server nodig en je hoeft niet steeds repository-URL’s in te typen als je merges doet.

Als het maar 2 mensen waren, zou ik zeggen dat git ook makkelijker is, omdat je gewoon kunt duwen en trekken van elkaar.

Als je dat echter voorbij bent, zou ik voor subversie gaan, omdat je op dat moment een ‘dedicated’ server of locatie moet opzetten.

Je kunt dit net zo goed doen met git als met SVN, maar de voordelen van git wegen niet op tegen de noodzaak om extra stappen te doen om te synchroniseren met een centrale server. In SVN leg je je gewoon vast. In git moet je git commit, dan git push. De extra stap wordt vervelend, simpelweg omdat je het uiteindelijk zo vaak doet.

SVN heeft ook het voordeel van betere GUI-tools, maar het git-ecosysteem lijkt snel in te halen, dus ik zou me hier op de lange termijn geen zorgen over maken.

Antwoord 15

Easy Githeeft een mooie pagina die het daadwerkelijke gebruik van Git en SVNdie je een idee geven van wat Git kan doen (of gemakkelijker doen) in vergelijking met SVN. (Technisch gezien is dit gebaseerd op Easy Git, een lichtgewicht wrapper bovenop Git.)

Antwoord 16

Git en DVCS zijn in het algemeen geweldig voor ontwikkelaars die veel onafhankelijk van elkaar coderen, omdat iedereen zijn eigen branch heeft. Als je echter een wijziging van iemand anders nodig hebt, moet ze zich committeren aan haar lokale opslagplaats en dan moet ze die wijzigingenset naar jou pushen of je moet het van haar terughalen.

Mijn eigen redenering doet me ook denken dat DVCS de zaken moeilijker maakt voor QA en releasebeheer als je dingen doet als gecentraliseerde releases. Iemand moet verantwoordelijk zijn voor het doen van die push/pull vanuit de repository van alle anderen, het oplossen van eventuele conflicten die zouden zijn opgelost tijdens de initiële commit-tijd, vervolgens het bouwen en vervolgens alle andere ontwikkelaars hun repo’s opnieuw laten synchroniseren.

Dit alles kan natuurlijk worden aangepakt met menselijke processen; DVCS heeft zojuist iets kapot gemaakt dat is opgelost door gecentraliseerd versiebeheer om wat nieuwe gemakken te bieden.

Antwoord 17

Ik vind Git leuk omdat het communicatieontwikkelaar tot ontwikkelaar helpt in een middelgroot tot groot team. Als een gedistribueerd versiebeheersysteem, door middel van zijn push/pull-systeem, helpt het ontwikkelaars om een broncode-ecosysteem te creëren dat helpt bij het beheren van een grote groep ontwikkelaars die aan een enkel project werken.

Stel bijvoorbeeld dat je 5 ontwikkelaars vertrouwt en alleen codes uit hun repository haalt. Elk van die ontwikkelaars heeft zijn eigen vertrouwensnetwerk van waaruit ze codes ophalen. De ontwikkeling is dus gebaseerd op dat vertrouwensweefsel van ontwikkelaars waar de codeverantwoordelijkheid wordt gedeeld door de ontwikkelingsgemeenschap.

Natuurlijk zijn er nog andere voordelen die hier in andere antwoorden worden genoemd.

Antwoord 18

Een paar antwoorden hebben hierop gezinspeeld, maar ik wil twee punten expliciet maken:

1) De mogelijkheid om selectieve commits te doen (bijvoorbeeld git add --patch). Als je werkdirectory meerdere wijzigingen bevat die geen deel uitmaken van dezelfde logische wijziging, maakt Git het heel gemakkelijk om een commit te maken die slechts een deel van de wijzigingen bevat. Met Subversion is het moeilijk.

2) De mogelijkheid om vast te leggen zonder de wijziging openbaar te maken. In Subversion is elke commit onmiddellijk openbaar en dus onherroepelijk. Dit beperkt de mogelijkheid van de ontwikkelaar om “vroeg vast te leggen, vaak vast te leggen” aanzienlijk.

Git is meer dan alleen een VCS; het is ook een hulpmiddel voor het ontwikkelen van patches. Subversion is slechts een VCS.

Antwoord 19

Ik denk dat Subversion prima is.. totdat je begint met mergen.. of iets ingewikkelds doet.. of iets doet waarvan Subversion denkt dat het ingewikkeld is (zoals het doen van queries om erachter te komen welke branches met een bepaald bestand hebben geknoeid, waarbij een wijziging eigenlijkvandaan komt, kopiëren en plakken detecteren, enz.)…

Ik ben het niet eens met het winnende antwoord en zeg dat het belangrijkste voordeelvan GIT offline werk is – het is zeker nuttig, maar het is meer een extraatje voor mijn gebruik. SVK kan ook offline werken, toch is er voor mij geen vraag in welke ik mijn leertijd moet investeren).

Het is gewoon ongelooflijk krachtig en snel en, goed – na gewend te zijn aan de concepten – erg handig (ja, in die zin: gebruiksvriendelijk).

Zie dit voor meer informatie over een samenvoegingsverhaal:
Git-svn gebruiken (of vergelijkbaar) *alleen* om te helpen met een svn merge?

Antwoord 20

Dankzij het feit dat het niet constant met een centrale server hoeft te communiceren, wordt vrijwel elk commando in minder dan een seconde uitgevoerd (uiteraard zijn git push/pull/fetch langzamer, simpelweg omdat ze SSH-verbindingen moeten initialiseren). Vertakking is veel eenvoudiger (één simpele opdracht om te vertakken, één simpele opdracht om samen te voegen)

Antwoord 21

Ik vind het geweldig om lokale takken van mijn broncode in Git te kunnen beheren zonder het water van de centrale repository te vertroebelen. In veel gevallen zal ik de code van de Subversion-server uitchecken en een lokale Git-repository uitvoeren om dit te kunnen doen. Het is ook geweldig dat het initialiseren van een Git-repository het bestandssysteem niet overal vervuilt met een heleboel vervelende .svn-mappen.

En wat betreft de ondersteuning van Windows-tools, gaat TortoiseGit met de basis heel goed om, maar ik geef nog steeds de voorkeur aan de opdrachtregel, tenzij ik het logboek wil bekijken. Ik hou echt van de manier waarop Tortoise{Git|SVN} helpt bij het lezen van commit logs.

Antwoord 22

Dit is de verkeerde vraag om te stellen. Het is maar al te gemakkelijk om je te concentreren op de wratten van git en een argument te formuleren over waarom subversie ogenschijnlijk beter is, althans voor sommige gebruikssituaties. Het feit dat git oorspronkelijk was ontworpen als een constructieset voor versiebeheer op een laag niveau en een barokke linux-ontwikkelaar-georiënteerde interface heeft, maakt het gemakkelijker voor de heilige oorlogen om grip en waargenomen legitimiteit te krijgen. Git-voorstanders slaan op de trommel met miljoenen workflow-voordelen, die volgens svn-jongens onnodig zijn. Al snel wordt het hele debat geframed als gecentraliseerd versus gedistribueerd, wat de belangen van de enterprise svn-toolgemeenschap dient. Deze bedrijven, die doorgaans de meest overtuigende artikelen publiceren over de superioriteit van subversion in de onderneming, zijn voor het succes van hun producten op de lange termijn afhankelijk van de waargenomen onzekerheid van git en de ondernemingsbereidheid van svn.

Maar hier is het probleem: Subversion is een architecturale doodlopende weg.

Terwijl je git kunt nemen en vrij gemakkelijk een gecentraliseerde subversie-vervanging kunt bouwen, ondanks dat het al meer dan twee keer zo lang bestaat, is svn er nooit in geslaagd om zelfs maar elementaire merge-tracking ergens in de buurt zo goed te laten werken als in git. Een fundamentele reden hiervoor is de ontwerpbeslissing om branches hetzelfde te maken als directory’s. Ik weet niet waarom ze oorspronkelijk op deze manier zijn gegaan, het maakt gedeeltelijk afrekenen zeker heel eenvoudig. Helaas maakt het het ook onmogelijk om de geschiedenis goed bij te houden. Het is duidelijk dat je de lay-outconventies van subversion-repository’s moet gebruiken om branches te scheiden van reguliere mappen, en svn gebruikt enkele heuristieken om dingen te laten werken voor de dagelijkse gebruiksgevallen. Maar dit alles is gewoon papierwerk over een zeer slechte en beperkende ontwerpbeslissing op laag niveau. Het kunnen doen van een repository-gewijs diff (in plaats van directory-gewijs diff) is een fundamentele en essentiële functionaliteit voor een versiecontrolesysteem, en vereenvoudigt de interne onderdelen aanzienlijk, waardoor het mogelijk wordt om er slimmere en nuttige functies bovenop te bouwen. Je kunt zien hoeveel moeite er is gestoken in het uitbreiden van subversie, en toch hoe ver het achterligt op de huidige generatie moderne VCS’en in termen van fundamentele operaties zoals samenvoegresolutie.

Hier is mijn oprechte en agnostische advies voor iedereen die nog steeds gelooft dat Subversion goed genoeg is voor de nabije toekomst:

Subversion zal nooit de nieuwere soorten VCS’en inhalen die hebben geleerd van de fouten van RCS en CVS; het is een technische onmogelijkheid, tenzij ze het repository-model van de grond af aan herstructureren, maar dan zou het niet echt svn zijn, toch? Ongeacht hoeveel je denkt dat je niet beschikt over de mogelijkheden van een moderne VCS, je onwetendheid zal je niet beschermen tegen de valkuilen van Subversion, waarvan vele situaties zijn die onmogelijk zijn of gemakkelijk kunnen worden opgelost in andere systemen.

Het is uiterst zeldzaam dat de technische minderwaardigheid van een oplossing zo duidelijk is als bij svn, zeker zou ik nooit zo’n mening geven over win-vs-linux of emacs-vs-vi, maar in dit geval het is zo duidelijk en broncontrole is zo’n fundamenteel hulpmiddel in het arsenaal van de ontwikkelaar, dat ik vind dat het ondubbelzinnig moet worden vermeld. Ongeacht de vereiste om svn om organisatorische redenen te gebruiken, smeek ik alle svn-gebruikers om hun logische geest geen valse overtuiging te laten construeren dat modernere VCS’en alleen nuttig zijn voor grote open-sourceprojecten. Ongeacht de aard van je ontwikkelingswerk, als je een programmeur bent, zul je een effectievere programmeur zijn als je leert hoe je beter ontworpen VCS’en kunt gebruiken, of het nu Git, Mercurial, Darcs of vele anderen zijn.

Antwoord 23

Subversion is heel gemakkelijk te gebruiken. Ik heb in de afgelopen jaren nooit een probleem gevonden of dat iets niet werkt zoals verwacht. Er zijn ook veel uitstekende GUI-tools en de ondersteuning voor SVN-integratie is groot.

Met Git krijg je een flexibelere VCS. Je kunt het op dezelfde manier gebruiken als SVN met een externe repository waar je alle wijzigingen vastlegt. Maar je kunt het ook grotendeels offline gebruiken en de wijzigingen alleen van tijd tot tijd naar de externe repository pushen.
Maar Git is complexer en heeft een steilere leercurve. Ik merkte dat ik voor het eerst verkeerde branches beging, indirect branches aanmaakte of foutmeldingen kreeg met niet veel informatie over de fout en waar ik met Google moest zoeken om betere informatie te krijgen.
Sommige eenvoudige dingen zoals het vervangen van markeringen ($Id$) werken niet, maar GIT heeft een zeer flexibel filter- en haakmechanisme om eigen scripts samen te voegen en zo krijg je alle dingen die je nodig hebt en meer, maar het heeft meer tijd en het lezen van de documentatie nodig 😉

Als je voornamelijk offline werkt met je lokale repository, heb je geen back-up als er iets verloren gaat op je lokale computer. Met SVN werk je meestal met een externe repository die tegelijkertijd ook je back-up is op een andere server…
Git kan op dezelfde manier werken, maar dit was niet het hoofddoel van Linus om zoiets als SVN2 te hebben. Het is ontworpen voor de Linux-kernelontwikkelaars en de behoeften van een gedistribueerd versiebeheersysteem.

Is Git beter dan SVN? Ontwikkelaars die alleen wat versiegeschiedenis en een back-upmechanisme nodig hebben, hebben een goed en gemakkelijk leven met SVN. Ontwikkelaars die vaak met branches werken, meerdere versies tegelijkertijd testen of voornamelijk offline werken, kunnen profiteren van de functies van Git. Er zijn enkele zeer handige functies, zoals stashing die niet worden gevonden met SVN, die het leven gemakkelijker kunnen maken. Maar aan de andere kant zullen niet alle mensen alle functies nodig hebben. Dus ik kan de doden van SVN niet zien.

Git heeft wat betere documentatie nodig en de foutrapportage moet nuttiger zijn. Ook de bestaande bruikbare GUI’s zijn slechts zelden. Deze keer heb ik maar 1 GUI voor Linux gevonden met ondersteuning van de meeste Git-functies (git-cola). Eclipse-integratie werkt, maar is niet officieel vrijgegeven en er is geen officiële update-site (alleen een externe update-site met periodieke builds van de trunk http://www.jgit.org/updates)
Dus de meest geprefereerde manier om Git tegenwoordig te gebruiken is de opdrachtregel.

Antwoord 24

Eric Sinkvan SourceGear schreef een serie artikelen over verschillen tussen gedistribueerde en niet-gedistribueerde versiebeheersystemen. Hij vergelijkt de voor- en nadelen van de meest populaire versiebeheersystemen. Zeer interessante lezing.
Artikelen zijn te vinden op zijn blog, www.ericsink.com:

Antwoord 25

Voor mensen die op zoek zijn naar een goede Git GUI, kan Syntevo SmartGiteen goede oplossing zijn. Het is propriëtair, maar gratis voor niet-commercieel gebruik, draait op Windows/Mac/Linux en ondersteunt zelfs SVN met een soort git-svn-bridge, denk ik.

Antwoord 26

http://subversion.wandisco.com/component/content /article/1/40.html

Ik denk dat het redelijk veilig is om te zeggen dat onder ontwikkelaars de SVN Vs. Het Git-argument woedt al een tijdje, waarbij iedereen zijn eigen mening heeft over wat beter is. Dit kwam zelfs ter sprake in de vragen tijdens ons webinar over Subversion in 2010 en daarna.

Hyrum Wright, onze directeur van Open Source en de president van de Subversion Corporation, vertelt over de verschillen tussen Subversion en Git, samen met andere Distributed Version Control Systems (DVCS).

Hij vertelt ook over de aanstaande veranderingen in Subversion, zoals Working Copy Next Generation (WC-NG), waarvan hij denkt dat het een aantal Git-gebruikers ertoe zal brengen terug te converteren naar Subversion.

Bekijk zijn video en laat ons weten wat je ervan vindt door op deze blog te reageren of door op onze forums te posten. Registratie is eenvoudig en duurt maar even!

Antwoord 27

Git in Windows wordt nu redelijk goed ondersteund.

Bekijk GitExtensions = http://code.google.com/p/gitextensions/

en de handleiding voor een betere Windows Git-ervaring.

Antwoord 28

Ik woon de laatste tijd in Git-land, en ik vind het leuk voor persoonlijke projecten, maar ik zou nog niet in staat zijn om werkprojecten naar Subversion over te schakelen, gezien de verandering in denken van personeel, zonder dringende voordelen . Bovendien is het grootste project dat we intern uitvoeren extreem afhankelijk van svn:externalswat, van wat ik tot nu toe heb gezien, niet zo mooi en naadloos werkt in Git.

Antwoord 29

Ten eerste lijkt gelijktijdig versiebeheer een eenvoudig op te lossen probleem. Het is helemaal niet. Hoe dan ook…

SVN is nogal niet-intuïtief. Git is nog erger. [sarcastische speculatie] Dit kan zijn omdat ontwikkelaars, die van harde problemen zoals gelijktijdige versiecontrole houden, niet veel interesse hebben in het maken van een goede gebruikersinterface. [/sarcastische-speculatie]

SVN-supporters denken dat ze geen gedistribueerd versiebeheersysteem nodig hebben. Dat dacht ik ook.Maar nu we Git exclusief gebruiken, ben ik een gelovige. Nu werkt versiebeheer voor mij EN het team/project in plaats van alleen voor het project. Als ik een filiaal nodig heb, filiaal ik. Soms is het een branch die een corresponderende branch op de server heeft, en soms niet. Om nog maar te zwijgen van alle andere voordelen die ik moet gaan bestuderen (mede dankzij het mysterieuze en absurde gebrek aan gebruikersinterface dat een modern versiebeheersysteem is).

Antwoord 30

Waarom ik denk dat Subversion beter is dan Git (tenminste voor de projecten waaraan ik werk), voornamelijk vanwege de bruikbaarheid en eenvoudigere workflow:

http://www.databasesandlife.com/why-subversion -is-beter-dan-git/

Waarom is git beter dan subversie?