Boss ist skeptisch, ein Versionskontrollsystem für ein neues Projekt zu verwenden, sollte ich das trotzdem tun?

Siehe /software/109817/superior-refusing-to-use-subversion

Meine Frage ist ähnlich, aber hier sind die Hauptunterschiede in meinem Szenario:

• Wir starten ein neues Projekt von Grund auf mit PHP und Web-Technologie. Es würde keine Ausfallzeit in der Entwicklung geben, da wir sie von Anfang an übernehmen würden, wenn ich meinen Willen hätte.

• Mein Entwicklerteam besteht aus mir und meinem Chef. Wir sind die "IT" -Abteilung eines relativ kleinen Unternehmens.

Die Web-App ersetzt eine Legacy-Anwendung ohne Quellcodeverwaltung. Aufgrund unterschiedlicher geografischer gesetzlicher Anforderungen wurde (bevor ich eingestellt wurde) die Entscheidung getroffen, die App für jede Version in 7 vollständig separate Verzeichnisse zu unterteilen. Danach haben verschiedene Entwickler zu unterschiedlichen Zeiten an verschiedenen Orten unterschiedliche Dinge getan. Patches über sie hinweg patchen, nun, ich denke, es könnte besser gemacht werden, ich denke, deshalb poste ich.

Der Vorschlag meines Chefs, direkt aus einer E-Mail eingefügt:

• Aktualisierungen sollten als Pakete im Ordner SUBMISSIONS eingereicht werden. Das Paket sollte alle relevanten Dateien sowie eine 'UPDATE.NFO'-Datei enthalten, die eine Beschreibung des Updates, eine Liste aller neuen Dateien (mit Beschreibungen) und eine Liste aller geänderten Dateien mit Änderungsdetails enthält.

• Aktualisierungspakete sollten sich auf ein einzelnes Element konzentrieren und nicht vom beabsichtigten Zweck abweichen. Der Code sollte modular aufgebaut und nach Möglichkeit wiederverwendbar sein.

• Alle eingereichten Pakete sollten kurz nach der Übermittlung in der Testumgebung jedes Entwicklers installiert werden. Jeder Entwickler muss den neuen Zusatz überprüfen und alle Bedenken hinsichtlich seiner Installation in der Produktionsumgebung äußern. Ein Standardpaket-Update sollte für diesen Überprüfungsprozess mindestens 3 Werktage lang aufbewahrt werden, bevor es in die Produktionsumgebung geladen wird. Updates / Fixes mit hoher Priorität können diese Anforderung überspringen.

Der Grund, warum die Quellcodeverwaltung erfunden wurde, ist, all das automatisch zu machen, oder? Ich schlug Subversion vor, weil ich das im College verwendet habe. Boss mag Subversion nicht, weil "es den Code durcheinander bringt" (dh binäre Magie verwendet und nicht klar lesbar ist). Wir haben es einmal versucht, aber ich denke, der Versuch, es unter Windows zu verwenden, hat seltsame Fehler in Klein- / Großbuchstaben verursacht und wir konnten unsere Dateien nicht auschecken. Ich weiß nicht, ob nur Subversion oder alle Quellcodeverwaltungsprodukte zu beanstanden sind.

Also, welche Art von Argument sollte ich meinem Chef vorbringen? Oder hat er recht und es besteht die Gefahr, dass wir all unsere Arbeit durch einen seltsamen Fehler verlieren?

Oder irre ich mich überhaupt? Ist eine Quellcodeverwaltung in meiner Situation wirklich notwendig? Dies ist unsere wichtigste geschäftskritische Software, über die wir sprechen. Sie wird also zweifellos sehr groß ausfallen. Aber es gibt nur 2 Entwickler (jetzt).

Wenn ich ihn nicht überzeugen kann, hätte es dann Sinn, es nur für mich selbst zu verwenden? Ich spreche als jemand mit sehr begrenzter Erfahrung, der tatsächlich svn benutzt. Alles was ich wirklich weiß ist Auschecken und Festschreiben. Welche Funktionen der Quellcodeverwaltung (möglicherweise auch andere Produkte als svn) unterstützen meine individuellen Entwicklungsanstrengungen?

Bitte keine "einen anderen Job bekommen" -Kommentare. Das ist für die Debatte nicht hilfreich.

Frag ihn nicht. Sag es ihm nicht. Zeige ihm.

Installieren Sie svn oder git oder was auch immer Sie möchten auf einem zusätzlichen Computer. Üben Sie es selbst, bis Sie sich wohl fühlen, es nicht nur zu benutzen, sondern es zu erklären. Wenn Sie ihn mit Ihrem neuen System vertraut machen möchten, müssen Sie selbst mehr als vertraut damit sein. Sie müssen ihm helfen können, sich leicht zu erholen, wenn er eine Zusammenführung vermasselt oder etwas an der falschen Stelle eincheckt.

Wenn Sie bereit sind, zeigen Sie ihm genau, wovon Sie sprechen. Zeigen Sie ihm, dass es nichts "durcheinander bringt". Weisen Sie darauf hin, dass Sie damit nicht nur problemlos eine frühere Version Ihres Codes abrufen können, sondern auch genau wissen können, was sich zwischen zwei Versionen geändert hat.

Weisen Sie darauf hin, dass Sie beide wie Helden aussehen , wenn dem Server jemals etwas passiert (schwerwiegender Fehler, Virus, Hacker, Festplattenabsturz ...) , wenn Sie die erforderliche Version sofort rekonstruieren können. Weisen Sie auch darauf hin, dass Sie doppelt so gut aussehen, wenn Sie eine beliebige Version auf Anfrage produzieren können. Durchsuchen Sie Ihre alte E-Mail und stellen Sie eine Liste der Probleme zusammen, die Sie im letzten Jahr hatten und die Sie mit der Versionskontrolle hätten vermeiden können.

Geben Sie ihm einen Spickzettel, der ihm die Verwendung Ihres Versionskontrollsystems erleichtert .

Schlagen Sie schließlich einige Optionen vor, aber überlassen Sie die Entscheidung ihm . Sollten Sie Ihren eigenen Server einrichten oder einen der vielen gehosteten Dienste verwenden ? Solltest du svn, git oder etwas anderes verwenden? Sollten Sie alle sieben Projekte auf das System migrieren oder es zunächst mit einem oder zwei versuchen?

Die Vorteile der Quellcodeverwaltung gehen weit über die Möglichkeit hinaus, dass mehrere Entwickler an einem einzigen Code arbeiten. Eric Sink, der Gründer von SourceGear , nennt einige überzeugende Gründe, die Quellcodeverwaltung als alleinigen Entwickler zu verwenden :

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

Eric hat auch eine sehr nette Anleitung zur Quellcodeverwaltung für Anfänger . Es gibt ein kostenloses Online- Mercurial-Tutorial von Joel Spolsky. Mercurial ist ein beliebtes verteiltes Versionskontrollsystem.

Als nächsten Schritt empfehle ich Ihnen, die Quellcodeverwaltung als alleiniger Entwickler lokal auf Ihrem Computer zu verwenden. Sehr bald wird Ihr Chef bemerken, dass Sie zu purer Magie fähig sind, beispielsweise innerhalb von Minuten, wenn nicht Sekunden, zu sagen, wie weit ein überkritischer Fehler zurückreicht, und dann würden Sie ihm genau sagen, welche Kundenkonten betroffen waren und vor allem behoben werden müssen Hölle bricht los. Oder in der Lage zu sein, Änderungen rückgängig zu machen, missbilligt der CEO superschnell.

Und bevor Sie versuchen, Ihren Chef zu überzeugen, möchten Sie sich vielleicht mit dem Thema Umgang mit Einwänden befassen . Es sind 101 Verkäufe.

Wenn dies nicht gelingt, fahren Sie so schnell wie möglich fort. Es macht nicht viel Sinn, Ihre Zeit damit zu verschwenden, an Windmühlen zu kippen.

Ja, die Verwendung der Quellcodeverwaltung, auch wenn nur für Sie, lohnt sich auf jeden Fall. Git zum Beispiel funktioniert sehr gut für einen eigenständigen Entwickler und ermöglicht es Ihnen, Dinge wie Verzweigen und Zusammenführen (mit möglichst geringen Kosten) zu tun und Ihre Änderungen zu versionieren, während Sie fortfahren.

Mit SVN - oder wirklich jedem Versionskontrollsystem - können Sie dies auch tun, aber das Zusammenführen ist etwas problematischer.

Wenn ich ihn nicht überzeugen kann, hätte ich dann Sinn, es nur für mich selbst zu verwenden?

Ja. Es ist von Vorteil, es nur für sich selbst zu verwenden. Sie erhalten einen Änderungsverlauf, damit Sie sehen können, was anders ist.

Nein. Es gibt keinen Vorteil, weil Ihr Chef Ihr Projekt zu vielen sinnlosen Nacharbeiten verurteilt hat, weil sie die Dinge verschmutzt haben.

Ich empfehle dringend, wie bereits vor der Verwendung von Git erwähnt. Der Grund Nr. 1 ist, dass jedes VCS im Katastrophenfall ein Sicherheitsnetz ist. Suchen Sie nach dem Aufkleber „Im Brandfall: Git Commit, Git Push, Verlassen des Gebäudes“. Der Code kann an einem anderen Ort gespeichert werden, aber nicht in einem Laptop, der kaputt gehen, gestohlen werden kann oder was auch immer ... selbst ein lokaler Netzwerkserver ist nicht der sicherste Ort für etwas so Wertvolles wie Code.

Nummer 2. Rückverfolgbarkeit von Änderungen, wer hat was wann getan usw. Zusammenführen, Rückgängig machen. Nummer 3. Diff das magische Werkzeug für # 2 und viele weitere Fälle. Nummer 4. Zweige Nummer 5. Tagging-Versionen, Releases usw.

Weitere Informationen zu einem der häufigsten Git-Workflows finden Sie hier: https://nvie.com/posts/a-successful-git-branching-model/

Ich weiß, dass die Verwendung von Git zunächst einschüchternd sein kann, aber es ist eine gute Investition für eine Fähigkeit und ein Muss für jedes Entwicklungsteam.

In Bezug auf Ihr Problem mit der Groß- und Kleinschreibung vermeiden Sie die Verwendung von Tortoise. Ich weiß, dass die meisten Leute es als GUI für Git verwenden, da es für SVN sehr häufig war. Daher ist es möglicherweise die erste Wahl, stattdessen die Befehlszeile oder eine andere GUI wie Github Desktop zu verwenden oder der SourceTree von Atlasian.