Was ist der effektivste / effizienteste Weg, um eine Anwendung mit mehreren Personen ohne Versionskontrolle zu entwickeln?

Einführung in meine Situation

Ich arbeite für eine kleine Webentwicklungsfirma. Wir haben ein Team von vier ASP.NET-Entwicklern, darunter ich. Bei fast allen unseren Projekten (> 98%) handelt es sich um Ein-Personen-Projekte, deren Fertigstellung etwa 1 bis 4 Wochen in Anspruch nimmt. Wir verwenden keine Quellcode- oder Versionskontrolle. Das einzige, was wir haben, ist ein freigegebener Ordner auf einem lokalen Server, der die neueste Quelle (== die Quelle der Live-Anwendung) aller Projekte enthält.

In den seltenen Fällen, in denen wir mit mehr als einer Person an einem Projekt arbeiten müssen, verwenden wir ... Beyond Compare. Ein oder zwei Mal am Tag fragen sich die Entwickler, ob sie eine Version haben, die kompiliert wird, und synchronisieren dann ihren Code mit Beyond Compare. Wenn nur zwei Leute an einem Projekt arbeiten, funktioniert dies "ziemlich gut", aber sobald ein dritter Entwickler in den Prozess eintritt, wird es zu einem unüberschaubaren Stück Müll. Vor allem, wenn alle anfangen, Änderungen an der Datenbank vorzunehmen.

Ich (und einer oder zwei meiner Kollegen) haben meinem Chef bereits mehrmals gesagt, dass wir eine Form der Quell- und Versionskontrolle wie Git, Mercurial oder TFS verwenden sollten (unser Chef ist sehr Microsoft-orientiert). Leider sieht mein Chef den Vorteil eines Wechsels zu einem Versionskontrollsystem nicht, da in seinen Augen jetzt alles in Ordnung ist und er nicht Zeit und Geld in die Einrichtung eines neuen Systems und die Sicherstellung aller investieren möchte weiß, wie man es benutzt. Selbst nachdem ich ihm die Vorteile erklärt habe (wie vereinfachte Zusammenarbeit, verschiedene Versionen einer Anwendung, sichereres Ändern von Code, ...), glaubt er immer noch nicht, dass dies etwas ist, was wir brauchen.

Von den vier Entwicklern haben nur zwei (einschließlich mir) Erfahrung mit der Quellcodeverwaltung (Git). Und diese Erfahrung ist sehr begrenzt. Ich kann ein Github-Repository auf meinen Computer klonen, einige Änderungen vornehmen, sie festschreiben und an Github zurückschieben. Das ist es.

Erklärung meines Problems / Anliegens

In ein paar Wochen werden wir anfangen, an einem ziemlich großen Projekt für unsere Standards zu arbeiten. Es wird wahrscheinlich 2-3 Entwickler ein paar Monate dauern, um es abzuschließen. Ich werde der Projektleiter sein (Projektmanager und Hauptentwickler) und ich werde für alles verantwortlich sein. Ich hatte einige Probleme mit unserem Beyond Compare-Ansatz und möchte diesen Weg nicht mit diesem großen Projekt beschreiten, für das ich verantwortlich sein werde.

Da bezweifle ich, dass wir das können

• einen eigenen Git-Server einrichten,
• Bringen Sie allen bei, mit Git und zu arbeiten
• Git erfolgreich in diesem großen Projekt einsetzen,

Ich bin interessiert, ob einer von Ihnen einige gute Möglichkeiten kennt, mehreren Personen die Zusammenarbeit an einem Projekt zu ermöglichen, ohne die Quellcode- oder Versionskontrolle zu verwenden.

Aktualisieren

Ich möchte mich bei allen für ihre Antworten und Kommentare bedanken. Hier ist der Plan:

1. Treffen Sie sich mit den Entwicklern, um sicherzustellen, dass alle Techniker mit der Implementierung der Quellcodeverwaltung übereinstimmen. Wir werden einen stärkeren Punkt ansprechen, wenn alle dahinter stehen.
2. Präsentieren Sie die Idee dem Chef und sagen Sie ihm, dass wir wirklich Quellcodeverwaltung brauchen .
3. Implementieren Sie es so schnell wie möglich.

Nehmen Sie sich einen Tag Zeit, um die Versionskontrolle zu installieren, und bringen Sie allen Projektmitarbeitern die Verwendung bei. Es ist nicht so schwer. Persönlich habe ich Git nicht verwendet, aber ich habe andere Versionskontrollsysteme eingerichtet und verwendet, und es ist nicht so schwer, sie zum Arbeiten zu bringen. Stellen Sie sicher, dass Sie eine auswählen, die in Ihre Entwicklungsumgebung integriert ist. Dies macht die Nutzung praktisch nahtlos.

Dies wird keine Zeitverschwendung sein.

Die Zeit , die Sie wird verlieren , wenn jemand Überschreibungen oder Löschungen einige Code werden Sie viel mehr kosten.

Wenn Sie nicht über die Versionskontrolle verfügen, müssen Sie außerdem übermäßig viel Zeit für die Sicherung Ihres Projekts aufwenden und sich Gedanken darüber machen, welche Version jeder hat und welche Version sich auf dem Server befindet usw.

Wenn Sie Ihren Chef überzeugen müssen, schätzen Sie den Zeitaufwand für die Einrichtung und Überwachung von Lösungen, die nicht zur Versionskontrolle gehören, und erhöhen Sie die Kosten für das Umschreiben um ein paar Tage. Vergessen Sie nicht, die Kosten für das manuelle Zusammenführen von Änderungen von 3 Entwicklern, die an derselben Quelldatei arbeiten, und die zusätzlichen Kosten für das falsche Zusammenführen hinzuzufügen. Gute Versionskontrolle gibt Ihnen dies kostenlos

Vergleichen Sie dies mit den Kosten für die Versionskontrolle - null (wenn Sie Open Source verwenden) und die Einrichtung - 3 Manntage.

Vergessen Sie nicht, dass ein späterer Fehler im Projekt mehr als einen Fehler kosten wird. Wenn Sie das gesamte Projekt aufgrund eines Fehlers wiederholen müssen, den jeder machen kann, kostet dies weit mehr als nur die Zeit für das Umschreiben, es könnte Ihren Chef den Ruf seiner Firma kosten.

Wenn Sie die Quelle in einem Ordner freigeben, können Sie dort auch Repos freigeben. Der Chef weiß nichts davon, außer dass sich dort ein .git-Ordner befindet.

Sie sollten niemals um Erlaubnis bitten müssen, um Ihren Job richtig zu machen - Seth Godin.

Richten Sie die Quellcodeverwaltung ein, lernen Sie deren Verwendung und sagen Sie es Ihrem Chef nicht. Normalerweise befürworte ich kein ungehorsames Management, aber in diesem Fall ist Ihr Chef dumm. Wenn Sie wirklich glauben, dass das Erlernen von git zu lange dauern wird, beginnen Sie mit einem vereinfachten Versionskontrollsystem wie svn - es macht nicht alle coolen Dinge, die git macht, aber es ist noch einfacher, sich ein grundlegendes Verständnis davon zu verschaffen.

Warten Sie nicht, bis Sie mittendrin und ernsthaft in Schwierigkeiten sind, bevor Sie etwas implementieren. Mach es einfach und erledige den Job.

Bearbeitet, um hinzuzufügen: Was Ihre Frage wirklich fragt, ist "wie mache ich Quellcodeverwaltung ohne Verwendung eines Quellcodeverwaltungssystems". Sie haben die Notwendigkeit erkannt, und ich denke, jeder hier sagt Ihnen wirklich dasselbe: Ohne ein Versionsverwaltungssystem gibt es keine vernünftige Methode zur Versionsverwaltung.

Ich habe nur Ihre Zusammenfassung vor mir, aber danach scheint es so, als würde Ihr Chef ein Argument für Zeit und Geld vorbringen, und Sie führen ein Argument für technische Überlegenheit an. Sie müssen sich um Zeit und Geld streiten. Lernen Sie die git-Vorgehensweise und behalten Sie eine Weile den Überblick, was Sie sparen können. Legen Sie dann Ihrem Chef ein Protokoll mit Einträgen wie "28.03.2011" vor. Joe musste 30 Minuten warten, bis er zu einem kompilierbaren Build zurückgekehrt war wir könnten also einen Merge -, Git - Merge - Befehl für sein letztes Commit ausführen, der ungefähr 5 Sekunden lang gewesen wäre "mit einer netten Summe am Ende.

Wenn Training und Einrichten eines Servers geschäftliche Hürden darstellen, gibt es unendlich viele Möglichkeiten, einen Git-Workflow einzurichten, einschließlich der Tatsache, dass nur ein Teammitglied tatsächlich Git verwendet, mit freigegebenen Ordnern für den "Server".

Weisen Sie Ihre Kollegen an, ihren Code in einen bestimmten freigegebenen Ordner zu kopieren, wann immer dies sinnvoll ist. Sie können für jeden von ihnen ein Repository führen und alle Versionsverwaltungsaufgaben selbst erledigen und langsam mehr und mehr der Versionsverwaltungsaufgaben auf sie übertragen, wenn Sie sicher genug sind, sie zu schulen. Dies ist bei weitem nicht der ideale Weg, aber im Vergleich zu dem, was Sie jetzt haben, sparen Sie Zeit beim Zusammenführen. Es ist einfacher, Ihren Chef mit weniger Team-Lernkurven zu überzeugen, und Sie erhalten alle gewünschten Rollback- und Versionierungsvorteile.

Ich mache nicht viel Datenbankarbeit, aber meines Wissens wird das Zusammenführen von Datenbankschemaänderungen von der Quellcodeverwaltung nicht sehr gut gehandhabt. Wenn diese Zusammenführungen schwierig sind, sollten Sie eine Prozessänderung in Betracht ziehen, bei der alle Datenbankänderungen über einen einzigen Gatekeeper erfolgen.

Das ist verrückt. Sie sollten ein VCS verwenden, auch wenn Sie alleine arbeiten. Die Verwendung eines VCS in einem Unternehmen sollte verboten werden. Mach es einfach. Jetzt sofort! Wirklich ... Sie brauchen von Anfang an keine fortgeschrittenen Sachen. GitHub und GitLab sind sehr einfach zu verwenden, aber ich bin sicher, dass Sie weitere Windows-kompatible Hosting-Dienste finden können, wenn Ihr Chef darauf besteht (auch wenn es nicht schwer ist, Git unter Windows einzurichten und zu verwenden).

Der Gedanke, den Sie fragen, ist unmöglich . Wenn mehrere Personen ohne Quellcodeverwaltung an demselben Projekt arbeiten, treten schnell viele Probleme auf, und da Sie der leitende Entwickler sind, müssen Sie sich mit ihnen befassen.

Nach meiner persönlichen Erfahrung wird es von zwei Entwicklern unmöglich , an einem Projekt ohne Quellcodeverwaltung zu arbeiten . Nicht drei. Nicht vier. Zwei. Wahrscheinlich können Sie die Situation mit zwei Entwicklern in Ausnahmefällen bewältigen : Wenn diese Entwickler sehr gut organisiert und professionell sind, wenn sie gut zusammenarbeiten, wenn sie sich leicht austauschen können (sich also zu denselben Zeiten im selben Raum befinden) Zeit) und wenn sie in der Lage sind, menschliche Fehler zu vermeiden (versehentliche Änderung der Datei, die im selben Moment von einer anderen Person geändert wurde, Löschen der von dieser Person vorgenommenen Änderungen).

In meinem Fall war es immer mehr oder weniger eine Katastrophe , zwei Personen ohne Versionskontrolle an einem Projekt zu beteiligen. In den besten Fällen hat eine Person geänderte Dateien an die zweite Person gesendet, und diese zweite Person hat ein Diff-Tool verwendet, um die Änderungen manuell anzuwenden. Im schlimmsten Fall verfolgte eine Person die von ihr vorgenommenen Änderungen und wendete sie jedes Mal erneut an, wenn die zweite Person den Quellcode änderte. Ergebnis: ein großer Verlust an Zeit, Geld und Produktivität.

Aus meiner Sicht und meiner eigenen Erfahrung sehe ich drei Lösungen für das Problem, das Sie haben:

• Installieren Sie eine Versionskontrolle, die einfach zu bedienen ist . Früher habe ich CollabNetSubversion als SVN-Server installiert. Es ist recht schnell und einfach einzurichten, wenn Sie sich überhaupt nicht um die Sicherheit kümmern . Wenn Sie Visual Studio verwenden, wird AnkhSvn möglicherweise installiert, damit die Entwickler den Quellcode problemlos in Visual Studio aktualisieren / festschreiben können.

• Überzeugen Sie Ihren Chef, dass der Joel-Test von einer Person geschrieben wurde, die seinen Job sehr gut kennt, und wenn der Joel-Test eine Versionskontrolle vorschlägt, gibt es dafür einen guten Grund. Schließlich kann er auch entscheiden, dass Entwickler keine IDE / Syntax-Hervorhebungswerkzeuge benötigen, um Code zu schreiben. Windows Notepad ist in Ordnung, nicht wahr? Und warum einen Internetzugang haben? Wir brauchen nur einen sehr, sehr alten PC mit Windows 3.1.

• Verlassen Sie diese Firma , da ich einige Zweifel habe, dass dort alles außer der Versionskontrolle perfekt und professionell ist.

Wenn Sie bei einem größeren Projekt kein VCS verwenden, weil Sie nicht die Zeit für die Einrichtung investieren möchten, ist dies wie eine lange Reise barfuß, weil Sie nicht die Zeit für das Anziehen von Schuhen investieren möchten.

Jedes VCS ist um Größenordnungen besser als keines.

Eine kinderleichte Möglichkeit, ein VCS einzurichten, ist TortoiseSVN (da Sie anscheinend C # verwenden, gehe ich davon aus, dass Sie unter Windows arbeiten). Sie erstellen ein Repository in einem von Ihnen ausgewählten lokalen Ordner (navigieren Sie zu diesem Ordner, klicken Sie mit der rechten Maustaste auf> TortoiseSVN> Repository hier erstellen). Geben Sie diesen Ordner in Ihrem Netzwerk frei (er sollte sich vorzugsweise auf einem Computer befinden, der immer verfügbar ist) und checken Sie ihn mit der URL aus file://computername/path/to/that/repository. Download ausgeschlossen, dies dauert nicht länger als eine Minute.

Ihre Antwort ist ein einfacher Link zu Ihrem Chef ... Mailen Sie ihm / ihr diese Seite und markieren Sie, wie oft die Wörter "quit" von Fachleuten vorkommen.

Während das Wort "dumm" wahrscheinlich so oft vorkommt, bin ich mir sicher, dass es Ihr Chef nicht ist. Es ist ihm einfach nicht klar, welchen absoluten Wert dies hat. Die Frage, die er sich stellen muss, lautet, welche geschäftsbezogene Frage zur gleichen Antwort führen würde.

Die Quellcodeverwaltung ist nur erforderlich, wenn die Anzahl der Entwickler in einem Projekt> 0 ist. Ich beginne zu glauben, dass man das gleiche über die kontinuierliche Integration sagen könnte ...

(-:

Als ASP.NET-Entwickler würde ich vorschlagen, dass Sie sich für Subversion, TFS oder Mercurial entscheiden - aber um ehrlich zu sein, spielt es keine Rolle, was Sie tun, solange Sie sich für etwas entscheiden. Ohne Versionskontrolle zu entwickeln macht überhaupt keinen Sinn - noch weniger, wenn die Tools mehr oder weniger kostenlos bereitgestellt werden können und der Aufwand für ihre Verwendung minimal ist.

TFS bietet Ihnen ein erstaunliches Maß an Integration. DVCS (Mercurial oder Git) bietet Ihnen wahrscheinlich die größte Flexibilität und Leistungsfähigkeit. Es gibt keinen guten Grund, dies NICHT zu tun.

Wenn ich von vorne anfangen würde, wäre es mit ziemlicher Sicherheit Mercurial.

Sobald Sie die Versionskontrolle haben, können Sie zu einem Build-Server (TFS, TeamCity) und von dort zu einer kontinuierlichen Integration übergehen und an diesem Punkt beginnen Sie, die Hand über die Faust zu gewinnen.

Um zu Ihrem Ausgangspunkt zurückzukehren:

Ich werde der Projektleiter sein (Projektmanager und Hauptentwickler) und ich werde für alles verantwortlich sein

Richtig, du bist verantwortlich , so Sie entscheiden Sie Versionskontrolle benötigen (weil Sie tun), Sie entscheiden , dass Sie einen Build - Server benötigen (weil Sie tun), Sie entscheiden , dass Sie ausfahrbaren Ausgabe von Ihrem Projekt vom ersten Tag haben müssen (denn wenn Sie es immer bereitstellen können - und damit mehr Tests ermöglichen) und die Bereitstellung in hohem Maße automatisiert ist, sind dies Schritte, die Sie unternehmen, um den Erfolg Ihres Projekts sicherzustellen (für die Sie verantwortlich sind ...).

Wie oben erwähnt, können Sie dem freigegebenen Ordner, den Sie bereits haben, ein Repository hinzufügen. Sie müssen keine Zeit für die Konfiguration eines Servers aufwenden, wenn Sie ein verteiltes Versionsverwaltungssystem wie Git, Mercurial oder Bazaar verwenden.

Ich würde empfehlen, entweder Git zu verwenden, da Sie bereits Erfahrung damit haben, oder Mercurial, das sich gut in Visual Studio integrieren lässt.

Wenn Sie in Zukunft von Ihrem Chef aufgefordert werden, zu TFS zu wechseln, ist dies immer noch besser, als überhaupt keine Versionskontrolle zu haben.

In meiner Powerbuilder-Zeit arbeitete ein ganzes Team an einer Reihe von Anwendungen, ohne die Quellcodeverwaltung zu verwenden. Oh, Powerbuilder hatte Quellcodeverwaltung, aber eigentlich benutzte ihm ein crapshoot war - wenn PB abgestürzt , während Sie eine Datei ausgecheckt haben (und es abgestürzt viel), dass propriatary, binäre Datei Source war jetzt nicht zugänglich. In der Datei wurde ein Flag gesetzt, und keine andere Kopie von PB konnte es laden, auch nicht die Person, die es ausgecheckt hatte.

Was wir also gemacht haben, war ziemlich einfach. "Hey, Tom, ich werde an xyz.pbl arbeiten. Nehmen Sie also keine Änderungen vor." Im großen Rahmen hatten wir selten Probleme.

Angenommen, Sie können Ihr Team nicht davon überzeugen, die Versionskontrolle zu übernehmen, oder Ihr Chef bekommt Wind von der List und besteht darauf, dass das Team aufhört, dann gibt es einen weniger als optimalen Ansatz, den Sie wählen können.

Installieren Sie Git oder Mercurial auf Ihrem eigenen Computer. Versionieren Sie Ihre eigene Arbeit. Wenn das Team seine Arbeit über den Beyond Compare-Prozess synchronisiert, fügen Sie die Änderungen als neues Commit zu Ihrem lokalen Repo hinzu. Sie können immer eine frühere Arbeitsversion von Ihrem lokalen Repository abrufen, wenn die Synchronisierung des Teams nicht funktioniert.

Die Verwendung eines DVCS stellt sicher, dass kein Server und kein komplexer Einrichtungsprozess erforderlich sind. Die Installation von Mercurial und der Einstieg in die Grundlagen sollten nicht länger als 30 Minuten dauern.

Es ist keine ideale Lösung, aber es ist besser als nichts.

Meine erste Reaktion darauf war, dass Sie bereits einen idealen Arbeitsprozess ohne Versionskontrolle haben. Sie scheinen alle eine gute Möglichkeit zu haben, das Zusammenführen zu verwalten und so weiter. Aus Managementsicht scheint dies eine gute Situation zu sein. Ich habe Teams getroffen, die die Versionskontrolle verwenden, aber mit dem Entwicklungsprozess selbst zu kämpfen haben.

Es ist also völlig sinnlos, wenn Sie Ihren Chef nur davon überzeugen, dass die Versionskontrolle einen "besseren Prozess" darstellt. Es gibt jedoch noch ein viel wichtigeres Argument warum Sie zuerst die Versions- oder Quellcodeverwaltung verwenden müssen, was sich leicht zu Geld rechnen lässt. Und das ist:

Risiko

Das Problem ist nicht, dass die Verwendung der Quellcodeverwaltung Ihren Entwicklungsprozess verbessert. Es ist eher ein Problem, was passieren würde, wenn Sie überhaupt keine Quellcodeverwaltung haben. Was sind die Risiken?

Angenommen, jemand löscht versehentlich eine Funktion im Code oder eine ganze Datei? Wie viel würde die Reparatur kosten? Hoffentlich hat jemand das erledigt, also ist der Fix marginal.

Aber was passiert, wenn kein Körper eine Sicherungskopie der verlorenen Datei hat? Wie viel Mannstunden würde die Reparatur kosten? Das würde vielleicht Tage dauern, und das lässt sich leicht in Mannstunden berechnen. Wäre das zu viel für die Firma? Könnte dies irgendwie schneller behoben werden?

Ja, mit einer Art Quellcodeverwaltung. Im Gegensatz dazu: Wie lange würde es dauern, die Versionskontrolle einzurichten und zu sichern? Die meisten Open-Source-Produkte wie Git oder Mercurial benötigen nicht viel Zeit für die Einrichtung. Den Leuten beizubringen, wie man es benutzt, wäre nicht so schwierig, wenn man bedenkt, dass man bereits weiß, wie man mit Beyond Compare zusammenarbeitet und in einen freigegebenen Ordner "eincheckt". Dies ist ein einmaliger Einrichtungsaufwand. Wären diese Mannstunden weniger als die, die die Risiken haben? Wenn dies zutrifft, sollte die Verwendung der Quellcodeverwaltung Vorrang haben.

Solange Sie einen Geschäftsgrund zeigen können, warum es nützlich ist, über eine Quellcodeverwaltung zu verfügen, und das Risikomanagement ein so großer Faktor wäre, der die meisten Chefs überzeugen würde.

Verwenden Sie ein verteiltes Versionskontrollsystem wie git und speichern Sie das Referenz-Repository auf Ihrem Computer mit freigegebenen Ordnern. Hier ist der Grund:

Jeder Klon ist ein Backup

Wenn die Serverfestplatte abstürzt, verfügt jeder über eine Kopie, die auf einem neuen Laufwerk oder Server bereitgestellt werden kann. Da Ihre Firma die Versionskontrolle nicht ernst meint, ist dies bei Backups wahrscheinlich nicht anders.

Gemeinsame Referenz

Wenn Sie ein Hauptrepository mit einem Hauptzweig haben, können Sie die Version ermitteln, die das letzte Wort enthält. Dies löst das Problem "Sie haben Ihre Änderungen gegen Francks Version getestet, aber hatten Sie auch John? Und wie haben Sie sie zusammengeführt?".

Liefern Sie bequemer

Der Kunde möchte heute eine Alpha-Version? Nun, Sie können testen, ob der Master stabil genug ist, und diesen ausliefern. Wenn dies nicht der Fall ist und Sie nicht die Zeit haben, es zu beheben, gehen Sie einfach in die Vergangenheit und holen Sie sich eine ältere, aber stabilere Version. Das können Sie nicht, wenn Sie nur die neueste Version haben.

Reise in die Vergangenheit und behebe deine Fehler

Ihre manuelle Zusammenführung hatte Probleme, die Sie erst nach ein paar Tagen sahen, aber Sie haben bereits den Inhalt Ihrer freigegebenen Ordner überschrieben? Ohne einen VSC haben Sie keine Vorgeschichte, so dass Sie nicht einfach zu einem Punkt zurückkehren können, an dem Sie die von Ihnen gemachten Fehler überprüfen und beheben können. Code ist nicht wie ein Bild, sondern wie ein Film: Er entwickelt sich mit der Zeit. Sie können ein Bild aus einem Film extrahieren. Sie können keinen Film aus einem Bild extrahieren.

Lokalisieren Sie Bugs einfacher

Es ist ein Fehler aufgetreten, den Sie jedoch zum Zeitpunkt der Einführung nicht wirklich bemerkt haben. Sie konnten ihn also nicht beheben, solange der Code "heiß" war. Jetzt wissen Sie nicht wirklich, welche Änderung sie eingeführt hat, sodass sie von verschiedenen Stellen im Code stammen kann. Es wird Stunden dauern, um herauszufinden, wo Sie suchen müssen. Mit git hätten Sie einfach einen Test entwickeln können, git bissectum festzustellen , ob der Fehler in einer bestimmten Version auftritt, und anhand dessen Sie das genaue Commit ermitteln können, das den Fehler verursacht hat. Anstatt nach Tausenden von Codezeilen zu suchen, wissen Sie jetzt, dass sich diese 10 Zeilen ändern, und Sie können den Test in Ihrer Testsuite behalten, um sicherzustellen, dass der Fehler nicht erneut auftritt.

Jeder Entwickler ist für seine eigene Arbeit verantwortlich

Wenn Sie der Teamleiter sind und kein VCS haben, müssen Sie höchstwahrscheinlich die Drecksarbeit erledigen, die Zusammenführungen. Wenn Sie es alleine machen, wissen Sie wahrscheinlich nicht alles über alle Änderungen und können Fehler verursachen. Im Gegenteil, wenn Sie immer die Personen, die den Code geschrieben haben, bitten, sich bei jeder Code-Zusammenführung mit Ihnen zu versammeln, wird diese Zeit nicht dazu verwendet, neuen Code zu erstellen.

Mit einem VCS muss sich der Entwickler in einem einfachen Workflow nur um seine Arbeit und eine externe Änderungsquelle kümmern: den Master-Zweig. Es können 1 oder 100 Personen in der Hauptniederlassung sein, das ist dasselbe. Um Änderungen vornehmen zu können, muss er sie an die neuesten Änderungen anpassen, die von anderen vorgenommen wurden. Es scheint, als würde es länger dauern, den Code zu pushen, aber das liegt daran, dass Sie auch die Zusammenführung durchführen, die ohnehin einige Zeit in Anspruch genommen hätte.

Der Unterschied besteht darin, dass die Zusammenführung von der Person vorgenommen wird, die die Änderungen vorgenommen hat. Diese Person kennt den Code am besten, weil sie ihn geschrieben hat.

Wer hat diesen Code geschrieben?

Es gibt diesen Fehler hier, aber wer hat diese bestimmte Codezeile geschrieben? Es ist schwer zu merken, besonders wenn das Projekt mehrere Monate dauert. git blamehätte dir gesagt, wer und wann diese Zeile geschrieben wurde, also kannst du die richtige Person fragen, und es gibt kein "Ich erinnere mich nicht, dass ich das geschrieben habe".

Das Projekt wird größer

Der Kunde möchte mehr Funktionen und Sie sind ein Team zu klein, Sie benötigen einen anderen Entwickler. Wie bewältigen Sie die erhöhte Zusammenführungskomplexität ohne VSC?

Dringende Änderungen

Der Kunde hat angerufen und um eine kritische Fehlerbehebung für die Produktion gebeten, aber Sie haben gerade an einer neuen Funktion gearbeitet. Sie müssen nur git stashIhre Änderungen beiseite legen oder in einer neuen Filiale festschreiben und die Änderungen vorantreiben, und schon können Sie an der dringenden Lösung arbeiten, ohne befürchten zu müssen, Ihre ausstehende Arbeit zu verlieren.

Es hat vor 10 Minuten funktioniert

Sie nehmen einige Änderungen vor Ort vor und etwas, das vor 10 Minuten funktioniert hat, funktioniert nicht mehr. Ohne ein VCS starrst du entweder auf den Code oder machst bestenfalls eine Kopie der Referenzversion und diff, um zu sehen, was du änderst. Oh warte, die Referenz hat sich geändert, seit ich angefangen habe zu arbeiten, also kann ich nicht mehr unterscheiden. Und ich dachte nicht daran, eine makellose Kopie des Codes aufzubewahren, auf dem ich meine Änderungen basierte.

Mit einem VCS machen Sie einfach etwas wie git diffsofort und haben Ihre Änderungen im Vergleich zur richtigen Version des Codes, auf dem Sie basieren.

Ich muss meine Debug-Protokolle aufbewahren

Also bist du ein böser Kerl und benutzt keine Protokollierung? Sie mussten printfs in all Ihre Codebasis streuen, bis Sie all diese Teile dieses bösen Insekts gefunden haben? Jetzt haben Sie einen gefunden, den Fehler behoben, möchten aber Ihren sorgfältig ausgearbeiteten Debugging-Code beibehalten, um verbleibende Probleme zu beheben.

Ohne ein VCS müssen Sie entweder die Dateien kopieren, den Debugging-Code (der möglicherweise einige Bearbeitungsfehler hinzufügt) löschen, diesen pushen und Ihre gesicherten Dateien zurückschreiben. Oh, aber es scheint, als wäre trotzdem ein Debug-Code reingekommen.

Mit git git add --patchwählen Sie einfach die wenigen Codezeilen aus, die Sie in Ihr Commit einfügen möchten, und können nur diese festschreiben . Dann nehmen Sie Ihre Arbeit wieder auf und haben immer noch Ihren Debugging-Code. Sie mussten den Code nicht berühren, daher kein Kopier- / Einfügefehler.

Der große Schlammball

Ohne ein VCS arbeiten die Leute auf ihrer Seite und geben Ihnen eine Reihe von Änderungen, manchmal ohne Beziehung. Wenn zu viel Code zum Überprüfen vorhanden ist, ist es schwierig, einen Fehler zu finden.

Mit einem VCS können Sie kleine, inkrementelle Änderungen vornehmen und ein Änderungsprotokoll erstellen. Das Changelog ist wichtig: Die Leute müssen dort erklären, warum sie die Änderung vornehmen , nicht was die Änderung ist ( welche Frage wird bereits durch die Codeänderung selbst beantwortet). Das heißt, wenn Sie beispielsweise einen Code einer neuen Funktion überprüfen, müssen Sie nicht viele nicht zusammenhängende gemischte Änderungen wie nicht zusammenhängende Bugfixes lesen. Dies hilft, sich auf den Code zu konzentrieren, den Sie interessieren.

Wenn ich dir 1 zu 1 100 Kartoffeln gebe und eine verfault ist, wirst du sie sofort finden. Wenn ich jetzt 100 Kartoffeln vor dir abwerfe und dich bitte, die faule zu finden, ist das nicht die gleiche Aufgabe.

Vertiefung

Ich hoffe, Sie haben eine gute Kodierungsrichtlinie. Andernfalls werden Änderungen an Einrückungen verrückt, wenn Sie von Hand zusammenführen. Natürlich können Sie Leerzeichen in den Änderungen ignorieren (aber nicht in Sprachen, wenn Einrückungen zählen, wie Python). Aber dann werden Sie merkwürdig aussehenden Code schwer zu lesen bekommen.

Sie sind der Projektleiter

Wenn Sie der Anführer sind, bedeutet dies, dass Sie die Schuld bekommen, wenn die Dinge nicht funktionieren. Wenn Sie sich mit der Situation nicht vertraut machen können, weil Ihr Chef immer noch nicht versteht, dass es sich lohnt, das richtige Werkzeug für den richtigen Job zu verwenden, dann würde ich mich zumindest weigern, der Anführer eines vorhersehbaren Fehlers zu werden.

Verwenden Sie Dropbox, es hat automatische Versionsgeschichte. Sie können Dropbox-Ordner für mehrere Benutzer freigeben.

Bearbeiten

Sie können auch den TortoiseSVN-Client herunterladen und ein "lokales Repository" auf dem Netzlaufwerk erstellen. Dann können die Benutzer den Quellcode nach Netzwerkordner auschecken.