Echt einfach hier Jungs. Beste Begründung bekommt den Sieg.
Ich bin Informatikstudent an einer Schule, von der Sie schon gehört haben, und programmieren seit einigen Jahren (etwa 8), also habe ich ein paar Zeilen Code geschrieben. Aber da ich nie wirklich verteilt habe - Quelle oder Binärdateien - noch Teamentwicklung betreibe (obwohl ich mir sicher bin!), Musste ich nie Quellcodeverwaltungssysteme lernen. Ich habe eine enorm langweilige Hierarchie von Ordnern in der Art von src/project_name oder src/class_code/hw_or_project_name , und wenn ich den Code an einen Freund oder eine Bewertung senden muss, ist es nur ein Tarball entfernt.
Einige Dinge haben sich in den letzten Jahren verändert, da meine Projekte größer geworden sind. Mein Mac mit Time Machine macht jetzt stündliche Backups - das hat mich ein paar Mal gerettet, zuletzt, als ich größere Änderungen an SSH vorgenommen habe ... und dann die veraltete Kopie einige Stunden später in meinem Editor gespeichert und geschlossen.
Aber aus einem beruflichen Interesse heraus - zusammen mit dem überwältigenden Gefühl, dass es nützlich sein könnte - habe ich beschlossen, SCMS zu lernen. Jetzt habe ich viel Erfahrung als Quellcode 'Consumer' - git clone , svn checkout , cvs co , diese Art von Sache - aber keine als Betreuer, Committer oder Updater.
Meine Frage an Sie lautet: Was soll ich lernen? Nun, ein paar von euch schreien "Warum? Du wirst viele benutzen!" aber ich würde gerne die Grundlagen von SCM lernen und die Gewohnheiten der tatsächlichen Verwendung auf dem einfachsten System anwenden. Es gibt eine Reihe von Konzepten, die ich gut verinnerlichen könnte - Zweige, Tags, Zusammenführung, Zusammenarbeit usw. - bevor ich sie wirklich brauche.
Um klar zu sein, ich bin kein Linus Torvalds. Ich werde einen oder vielleicht ein paar Zweige halten. Auf meinen dutzenden Dateien macht es mir nichts aus, wenn einige Operationen auf einem System einige hundert ms mehr benötigen als auf anderen.
Was habe ich jetzt? Ich habe einen Webhost. Sie bieten Subversion Hosting einen Klick entfernt, oder ich könnte andere Repositories dort kein Problem speichern. Aus Gründen, die ich nicht erklären kann, bin ich eher subversiv gegenüber Subversion. Aber genau deshalb zögere ich, einfach reinzuspringen. Ich weiß, Mercurial, Git und so weiter sind die heißen neuen Dinge, die verteilt werden, aber ich bin nicht sicher, warum das ein Vorteil ist. In der Tat bin ich nicht ganz sicher, wie es funktionieren könnte.
Also, womit soll ich anfangen? Subversion oder Git? Mercurial oder CVS? Visual Source Safe oder Perforce? (Das letzte Paar war ein Witz) Und warum einer über den anderen?
Vielen Dank für Ihre Zeit, und wenn dies in der falschen Sektion ist, entschuldige ich mich.
BEARBEITEN Vielen Dank! Ich freue mich über Ihre Kommentare. Angesichts der Wahl zwischen Git und Hg, würde ich wahrscheinlich mit Git gehen - jede Meinungsverschiedenheit? Zweitens, warum nicht Subversion? Es scheint der Konsens (nicht nur hier) zu sein, dass er alt oder anderweitig obsolet ist. Warum ist das?
EDIT 2 Nachdem ich alle Antworten gelesen und ein wenig mehr gelesen habe, habe ich beschlossen, mit Git zu gehen. "Antwort" geht auf die beste Begründung, wie oben erwähnt. Git scheint beliebter zu sein als Mercurial, auch wenn es ein bisschen weniger sauber ist. Ich dränge Änderungen auf meinen Webserver, wo ich viewgit installiert habe, und es funktioniert großartig. Der Anstoß zum Speichern einer Kopie auf meinem Webserver ist, dass ich gerne von mehreren meiner Maschinen aus arbeiten würde und ich erwarte, dass sie nicht mehr synchron sind. Ich erwarte auch, dass die verschiedenen Arbeitskopien nicht mehr miteinander und mit meinem Server synchronisiert sind, und ich verstehe jetzt, dass Subversion ziemlich schwach darin ist. Es gibt eine Menge, die ich noch auszuarbeiten versuche, aber ich habe es jetzt eingerichtet, damit ich von http ziehen / klonen kann und über ssh drehe (nächster Schritt ist Gitosis einzurichten). Für einen Neuling, der versucht, das zu tun, was ich gerade tue - Sie werden feststellen, dass Ihre "Push" -Befehle beim ersten Mal funktionieren, aber alle "geklonten" Kopien werden die von Ihnen vorgenommenen Änderungen nicht verfolgen. Git hält dies für ein Sicherheitsmerkmal ... Ich verstehe nur ein wenig warum, aber es hat mit der Verschmelzung zu tun. Der Trick besteht darin, diesen Post-Update-Hook auf dem Server zu verwenden, um die neu gepushte Kopie in den Server zu integrieren kopieren.
Angesichts der Wahl zwischen Git und Hg würde ich wahrscheinlich mit Git gehen - keine Meinungsverschiedenheit?
Warnung, ich bin ein merkwürdiger Fanboy.
Git ist nicht schlecht, aber es hat einige Macken, die du wissen musst, wenn du es benutzt:
hg up -r null freilegen und eine Arbeitskopie mit hg up [some-revision] von einem bare bekommen). git revert und svn revert vollständig verschiedene Dinge tun. git tag erstellt standardmäßig lokale Tags. Wenn Sie ein global sichtbares Tag möchten, benötigen Sie git tag -a oder git tag -s . Umgekehrt erstellt hg tag ein global visible Tag, lokale Tags werden mit hg tag -l erstellt. Einige Dinge, die viele an mercurial nicht mögen:
git rebase -i equivalent, das mit mercurial verpackt ist. Sie müssen die Drittanbieter-histedit-Erweiterung herunterladen dich selbst. Zweitens, warum nicht Subversion? Es scheint der Konsens (nicht nur hier) zu sein, dass er alt oder anderweitig obsolet ist. Warum ist das?
Svn hat keine Ahnung, was eine Verzweigung oder ein Tag ist, es kennt nur Kopien. Verzweigungen und Tags werden simuliert, indem man die Konvention hat, dass ein Svn Repo einen Stamm /, Zweige / und Tags / Ordner enthält, aber für Svn sind es nur Ordner.
Das Zusammenführen war ein Problem in svn, weil ältere Versionen (vor svn 1.5) den Zusammenführungsverlauf nicht verfolgen konnten. Seit svn1.5 subversion kann merge history verfolgen, aber ich weiß nicht, ob der merging Teil jetzt besser ist.
Eine andere Sache ist, dass in SVN jede Datei und jeder Ordner seine eigene Versionsnummer hat. In git und hg gibt es eine Version für die gesamte Verzeichnisstruktur. Das bedeutet, dass Sie in svn eine alte Revision in einer Datei auschecken können und svn sagt, dass Ihre Arbeitskopie keine lokalen Änderungen enthält. Wenn Sie eine alte Revision einer Datei in git oder hg auschecken, sagen beide Werkzeuge, dass Ihre Arbeitskopie schmutzig ist, weil die Struktur nicht mit ihrer gespeicherten Struktur übereinstimmt. Mit Subversion kannst du eine Frankenstein-Version deiner Quellen bekommen, ohne es zu wissen.
Ein kleiner Fehler in SVN ist, dass es einen .svn-Ordner in jeden ausgecheckten Ordner legt (ich habe Gerüchte gehört, dass sie dieses Verhalten in 1.7 ändern wollen), wo die sauberen Referenzdateien für die ausgecheckten Dateien existieren. Dies macht Tools wie grep -r foo nicht nur die echten Quelldateien, sondern auch Dateien aus diesen .svn Ordnern auflisten.
Svn hat einen Vorteil, wenn Sie große oder nicht verwandte Projekte haben, da Sie nur Teilbäume eines Repositorys auschecken können, während Sie in git und hg nur den gesamten Baum auf einmal erhalten können. Außerdem unterstützt svn das Sperren, was ein interessantes Feature ist, wenn Sie Dateien haben, die nicht einfach zusammengeführt werden können.
Die Schlüsselwortersetzung wird auch von svn unterstützt, aber ich würde dies nicht als Feature bezeichnen.
Ich würde mercurial wählen.
Der Fall Mercurial over subversion ist ziemlich überzeugend im ersten Abschnitt von Ссылка
gemachtGit und Mercurial können jetzt gegenseitig die Repos über den Draht lesen und schreiben, also kommt es wirklich auf die von Ihnen bevorzugte Schnittstelle an.
Ich habe Mercurial benutzt und es sehr genossen. Sie können ein kostenloses Bitbucket-Konto erhalten und Ihre Repos in der Cloud speichern. Es wird auch bei einigen Codeplex-Projekten verwendet, wenn Sie jemals die Möglichkeit haben, an einem OSS-Projekt zu arbeiten, das auf Codeplex basiert.
Der Grundgedanke, den ich gefunden / gehört habe, ist, dass Mercurial etwas einfacher zu bearbeiten ist, aber nicht so mächtig wie Git. Beide sind jedoch eine ausgezeichnete Wahl.
Es gibt ein wirklich gutes kostenloses Video auf tekpub für Mercurial und Codeplex . Es führt Sie durch alle Grundlagen.
Wie bereits erwähnt, ist der Link Ссылка eine weitere gute Ressource. Es wird auch von dem gleichen Team gemacht, das FogBugz & amp; Ofen. Kiln ist eine integrierte Umgebung für Mercurial und FogBugz mit Extras wie Code-Review.
Ich habe SVN auf meiner lokalen Box verwendet, um meine persönliche Arbeit zu speichern, aber nicht mehr. Mit Bitbucket & amp; Mercurial Ich muss mir keine Sorgen machen, dass meine lokale Kiste stirbt und dass ich alles gesichert habe ....
Unter dem Strich kannst du weder mit Hg noch mit Git schief gehen, aber ich würde mit Hg gehen, wenn du nicht einige der fortgeschrittenen Funktionen brauchst, die sich so anhört wie du nicht.
Das Lernen von SVN ist nicht unbedingt schlecht, da viele Organisationen es verwenden, aber ich würde mich stattdessen wirklich auf Distributed VCS konzentrieren. Sie sind wirklich die Zukunft. : -)
Da ich selbst ein Neuling bin, habe ich Git benutzt und finde es bemerkenswert einfach zu bedienen und intuitiv, während die anderen ein bisschen zu überwältigend waren. Zusammen mit GitHub macht es ein wundervolles kleines Werkzeug für die Quellcodeverwaltung, das Teilen und die Unterstützung up-Code.
Die beste Open-Source-Wahl ist GIT. Überprüfen Sie die Git-Dokumentation . Sie würden auch viele Tutos über das Internet (youtube, und einige Entwickler Blogs) finden. Ein Muss ist nicht (starten Sie CVS oder Subversion). Zumindest ist meine persönliche Meinung.
Es war einmal cvs fast vollständig ersetzt seine Konkurrenz und regierte die Welt der Versionskontrolle.
Dann wurde es selbst durch svn ersetzt.
Und jetzt wird svn durch git ersetzt.
Git ist komplexer als svn , so dass noch Gründe sein könnten, svn für ein neues auszuwählen Projekt.
Aber seine Tage sind gezählt. Git , Mercurial und einige proprietäre Systeme sind eindeutig die Zukunft der VCS-Welt.
Sowohl git als auch svn können in einem cvs-ähnlichen Checkout- / Pull- / Commit-Modus verwendet werden, also ist die bodenlose Grube der Komplexität (es ist ein Lebensstil), die git Sie nicht beeinflussen wird, wenn Sie in das tiefe Ende springen / p>
Tags und Links git svn mercurial version-control cvs