Zusammenfassung Versionsverwaltungen SVN , GIT

[haentschman]

Da es noch Programmierer gibt, die die Vorteile eines Versionskontrolsystems nicht schätzen, hier nochmal für die Einsteiger die Tutorials zusammengefaßt. :wink:

negative/falsche Aussagen (kommentiert):

Zitat:

Sehr viele Leute haben mir berichtet, dass das Installieren und Konfigurieren von VCS gar nicht so einfach ist

...Installation und Einrichten ist ein Zeitaufwand von ca. 1 Stunde. (SVN) :gruebel:

Zitat:

Ein Versionskontrollsystem bedeutet Anfangs Kopfschmerzen pur.

...verstehe ich nicht. :gruebel: Mit dem Versionskontrolsystem arbeitest du mit den gleichen Dateien wie du sie aus dem Exporer/Projekt kennst.

Zitat:

Ich bin absolut dagegen meinen Quellcode irgendwo im Netz oder lokal auf dem PC von einem Tool speichern zu lassen.

...die Originaldateien liegen nach wie vor am gleichen Platz. Im Versionskontrolsystem liegen sinngemäß die Änderungen der Dateien als Kopie.

Zitat:

Denn man weiß nicht einmal wo genau die Daten sind und nicht einmal welche.

...exakt die gleichen aus den gleichen Ordnern des Projektes. 8-)

Zitat:

Mit einem Versionskontrollsystem müsste man erst umständlich den alten Zustand wiederherstellen.

...3 Klicks. :gruebel: Wenn man möchte, auch mehrere Dateiversionen zurück. :thumb:

Zitat:

Und warum so unnötig kompliziert Daten wiederherstellen, wenn man sie auch gleich durch simples Umkopieren woanders ablegen kann?

...das Umkopieren entfällt!

Zitat:

Ohne Versionskontrollsystem Ausserhalb der VMs am besten immer nur gepacke Projekte als zip,rar,7z speichern und lagern ...

...da eine Änderung, in dem ZIP, finden ist quasi unmöglich. Wenn eine gezippte Datei in 2 verschieden Projekten verwendet wird, welche Version willst du zurückkopieren?

Zitat:

Ich möchte jederzeit ein einfaches Backup machen können, einen Clone...

...du kannst jederzeit sowohl deine Originaldateien als auch das Repository als Backup ablegen.

Zitat:

...ich möchte jederzeit Zugriff auf meine Dateien haben und sie nicht in einem System verlieren...

...hast du doch. :gruebel:

Zitat:

...das ich nicht mehr durchschaue.

...man muß sich darauf einlassen und lernen. 8-)

Zitat:

für den einzelnen Entwickler sind sie einfach nur lästig und überflüssig.

...das sollte nicht kommentiert werden. :?



Tutorials by Sebastian (Entwickler-Ecke)

SVN:
https://www.entwickler-ecke.de/topic..._112612,0.html

GIT:
https://www.entwickler-ecke.de/topic..._115462,0.html

[Sherlock]

:shock:

Die Aussagen hast Du Dir doch gerade ausgedacht!
Manche Antworten erscheinen mir aber für den Rahmen eines Tutorials etwas knapp.

Sherlock

[Ghostwalker]

Als jemand der selbst mal gegen Versionscontroll-System war sag ich jetzt einfach mal :thumb:

Vielleicht noch die ein oder andere Ergänzung:

Zitat:

Und warum so unnötig kompliziert Daten wiederherstellen, wenn man sie auch gleich durch simples Umkopieren woanders ablegen kann?

Weil das das VCS bereits mit übernimmt.

Zitat:

Ohne Versionskontrollsystem Ausserhalb der VMs am besten immer nur gepacke Projekte als zip,rar,7z speichern und lagern ...

Weil ein VCS etwas mehr als ein simples Backup ist. Es vewaltet die Änderungen an allen Dateien eines Projektes, so das sich alle Versionen wiederherstellen lassen. Ein Backup in einem Archiv würd ich nur zusätzlich bei erreichen eines Milestones machen.

Zitat:

...das ich nicht mehr durchschaue.

Dann fehlt dir die Organisation des Quelltextes. Das aber hat nix mit einem VCS zu tun.

Zitat:

für den einzelnen Entwickler sind sie einfach nur lästig und überflüssig.

Lästig nur am Anfang (bis es zur Routine wird). Überflüssig nur wenn dir dein Quelltext nicht wichtig ist.


und noch ein Kommentar zum Kommentar :):

Zitat:

Sehr viele Leute haben mir berichtet, dass das Installieren und Konfigurieren von VCS gar nicht so einfach ist

Zitat:

...Installation und Einrichten ist ein Zeitaufwand von ca. 1 Stunde. (SVN)

hmm...also mit Tortoise brauch ich dafür 15 Min.


LINKS:

Tortoise SVN mit Doku (einfacher Windows-Client/Server)

Tortoise Git-Client mit Doku usw.

[haentschman]

Zitat:

Die Aussagen hast Du Dir doch gerade ausgedacht!

...NÖ. Die sind aus einem kürzlichen Thread kopiert. (ohne Namen zu nennen)

Zitat:

Manche Antworten erscheinen mir aber für den Rahmen eines Tutorials etwas knapp.

Das sollte kein Tutorial sein. Die Arbeit hat ja Sebastian gemacht. Ich konnte diese Aussagen nicht so stehen lassen und Einsteigern die Links mitgeben. :P

Titel angepaßt...

[Sherlock]

Zitat:

Zitat von haentschman (Beitrag 1372477)

Das sollte kein Tutorial sein.

Ich hatte ganz kurz eine Existenzkrise... schaute nach dem Titel, und dann las ich weiter. :D

Zitat:

Zitat von haentschman (Beitrag 1372477)

Titel angepaßt...

:cyclops:

Danke für den kleinen Schubs am Morgen.

:thumb:

Sherlock

[Sherlock]

Ach, übrigens:
Please. Stop using Git.

Sherlock

[SneakyBagels]

Zitat:

...das Umkopieren entfällt!

Falsch. Ein Umkopieren findet trotzdem statt nur macht es nicht der Nutzer selber. Ich kopiere lieber selber um und weiß ganz genau was ich kopiere, als dass ich das irgendeine Software machen lasse die man nicht einmal richtig versteht und DAS zu erlernen ist Zeitverschwendung pur.

Zitat:

...da eine Änderung, in dem ZIP, finden ist quasi unmöglich. Wenn eine gezippte Datei in 2 verschieden Projekten verwendet wird, welche Version willst du zurückkopieren?

Komisch. Ich habe bisher immer alles ganz genau und sofort wiedergefunden. Und ich habe mittlerweile rund 20 Gigabytes (~200 an der Zahl) an ZIP-Dateien.
Mit einer ordentlichen Benennung findet man alles immer sofort wieder. Wer seinen Quellcode kennt, findet auch den alten Code direkt wieder.

Zitat:

...man muß sich darauf einlassen und lernen.

Zeitverschwendung pur. Manuelles rumkopieren oder ZIP-Dateien, das ist viel schneller. Das kann wohl jeder PC-Nutzer. Aber GIT und all der Spaß ist was für Enthusiasten, nicht aber für Leute die einfach nur Spaß an der Programmierung haben und keinen neuen, komplizierten und für sie unnötigen Mist lernen wollen.

Zitat:

Überflüssig nur wenn dir dein Quelltext nicht wichtig ist.

Halte ich für eine völlig sinnbefreite und stupide Antwort.
Du sagst also, dass demjenigen, der kein SVN und wie sie nicht alle heißen nutzt, sein Quellcode NICHT wichtig ist. So so. Das wusste ich noch nicht.

[himitsu]

Zitat:

Falsch. Ein Umkopieren findet trotzdem statt nur macht es nicht der Nutzer selber. Ich kopiere lieber selber um und weiß ganz genau was ich kopiere, als dass ich das irgendeine Software machen lasse die man nicht einmal richtig versteht und DAS zu erlernen ist Zeitverschwendung pur.

Es werden aber auch nur die Änderungen kopiert und nicht immer wieder alles.

Und man hat ein übersichtliches Log über alle Änderungen, was bei Einzelkopien nicht möglich ist.
Da mußt du dir auch erstmal einen Verzeichnissdiff von irgendeinem Programm erstellen lassen und hast da NUR die einen Unterschiede zwischen den zwei gerade verglichenen Verzeichnissen/Dateien.

[Whookie]

Zitat:

Zitat von sherlock (Beitrag 1372487)

ach, übrigens:
please. Stop using git.

sherlock

<ot> +1 :-D </ot>

[Sherlock]

Zitat:

Zitat von SneakyBagels (Beitrag 1372488)

Ich kopiere lieber selber um und weiß ganz genau was ich kopiere, als dass ich das irgendeine Software machen lasse die man nicht einmal richtig versteht und DAS zu erlernen ist Zeitverschwendung pur.

Du weisst aber genau wie ZIP funktioniert? Respekt! Ich kenne zwar die (Informations)Theorie dahinter, aber die konkrete Implementierung bleibt mir verborgen. Du verwendest auch Delphi, Windows und weitere Produkte, über deren Funktionsweise man zwar trefflich theoretisieren, über konkrete Implementierungen aber wenig bis gar nichts an die Öffentlichkeit gedrungen ist. Das Argument ist also - kurz gesagt: Nicht valide.

Was ich gerne zulasse ist der Hobbyisten Ansatz. Darüber kann man auch gar nicht streiten. Ich will nur so viel sagen: Irgendwann wirst Du alt, eventuell vorher schon sorglos und Dein Benennungsschema für die ZIP-Archive geht in die Binsen. Dann wars das mit der "einfachen" Ortung einer bestimmten Version.

Wichtiger noch ist das Auffinden einer bestimmten Änderung, bzw. dem Zeitpunkt wann diese Änderung in den Code gekommen ist. Wenn das (wie bei Software nicht unüblich) mehr als ein paar Monate zurück liegt, herzliches Beileid und viel Erfolg bei der ZIP-Sichtung.

Wie gesagt: Im Hobby-Fall eventuell vertretbar, aber ich würde mir das nicht antun wollen. Versionskontrolle ist viel weniger Hexenwerk als Kompression oder Compilierung.

Sherlock

[Bernhard Geyer]

Zitat:

Zitat von SneakyBagels (Beitrag 1372488)

Zitat:

...das Umkopieren entfällt!

Falsch. Ein Umkopieren findet trotzdem statt nur macht es nicht der Nutzer selber. Ich kopiere lieber selber um und weiß ganz genau was ich kopiere, als dass ich das irgendeine Software machen lasse die man nicht einmal richtig versteht und DAS zu erlernen ist Zeitverschwendung pur.

Zitat:

...da eine Änderung, in dem ZIP, finden ist quasi unmöglich. Wenn eine gezippte Datei in 2 verschieden Projekten verwendet wird, welche Version willst du zurückkopieren?

Komisch. Ich habe bisher immer alles ganz genau und sofort wiedergefunden. Und ich habe mittlerweile rund 20 Gigabytes (~200 an der Zahl) an ZIP-Dateien.
Mit einer ordentlichen Benennung findet man alles immer sofort wieder. Wer seinen Quellcode kennt, findet auch den alten Code direkt wieder.

Zitat:

...man muß sich darauf einlassen und lernen.

Zeitverschwendung pur. Manuelles rumkopieren oder ZIP-Dateien, das ist viel schneller. Das kann wohl jeder PC-Nutzer. Aber GIT und all der Spaß ist was für Enthusiasten, nicht aber für Leute die einfach nur Spaß an der Programmierung haben und keinen neuen, komplizierten und für sie unnötigen Mist lernen wollen.

Zitat:

Überflüssig nur wenn dir dein Quelltext nicht wichtig ist.

Halte ich für eine völlig sinnbefreite und stupide Antwort.
Du sagst also, dass demjenigen, der kein SVN und wie sie nicht alle heißen nutzt, sein Quellcode NICHT wichtig ist. So so. Das wusste ich noch nicht.

Also wir haben hier noch "Altlasten" die mit dieser High-End Bastellösung arbeiten.
Die Vorteile dieser Lösung:

- Quellcode-Dupleten en mass. Fehler die in gemeinsamen Units einmalig behoben wurden (und im Quellcodeveraltungssystem für alle verfügbar sind) schwirren noch in diesen High-End-Ziparchtiven herum

- Keinerlei Review-Prozess möglich. Bei der Enthusiasten-Fraktion werden alle Quellcodeänderungen zu den Tickets abgelegt so das man mit einem Klick im Ticketsystem (hier Jira) sieht was geändert wurde und ohne mit Zipdateien-Auspacken und Winmerge-Aufrufen ein Review möglich ist.

- Wiederverwendung von Funktionalität wird erfolgreich vermieten. Alle Quelldaten von Projekten die aktuell nicht bearbeitet werden liegen in Zip-Datei so gut verpackt vor, das man nicht auf die Idee kommt mal über einen einfache Suche über ein ausgechecktes Repository nach evtl. vorhandener ähnlicher/gleicher Implementierung zu suchen.

[haentschman]

@SneakyBagels

Zitat:

Zeitverschwendung pur. Manuelles rumkopieren oder ZIP-Dateien, das ist viel schneller. Das kann wohl jeder PC-Nutzer. Aber GIT und all der Spaß ist was für Enthusiasten, nicht aber für Leute die einfach nur Spaß an der Programmierung haben

...Zeitverschwendung? Um sich weiterzuentwickeln? :roll: Ohne Worte.

Zitat:

und keinen neuen, komplizierten und für sie unnötigen Mist lernen wollen.

...da kann man dir nicht helfen. Schade. :roll: Du redest über Dinge die noch nie ausprobiert hast... alles Hörensagen. :roll:

[jobo]

Also auch wenn ich die gelieferten Contras teilweise nicht sehr qualifiziert empfinde, kann man vielleicht schon nach "Einzelanwender" und "Teamentwicklung" und entsprechenden Anforderungen unterscheiden.
Aber
Angenommen es gibt ein geniales Namensschema für gezippte Delphisourcen einer OneManShow, was alle Suchanforderungen abbildet, dann ist ziemlich offensicht, was passieren wird, wenn dieses Genie mit einem Kollegengenie eine Firma gründet.

Anonsten leisten diese Tools einfach und die verschiedenen Frontends dazu viel mehr, als ZIP Archive es könnten. Branching, Ticketintegration, Diff Darstellung, .. wurde schon genannt.

[bra]

Ich kann auch jedem Hobbyprogrammierer - gerade auch für Anfänger - nur empfehlen, irgendeine Form von Versionsverwaltung zu nutzen, da man hier schnell, komfortabel und ohne großen Aufwand auch nachträglich noch nachvollziehen, was man irgendwann mal geändert hat.

Irgendwelchen Quatsch mit ZIP-Dateien umkopieren dagegen... mal ehrlich, das ist doch ein Witz oder? :lol:

[SneakyBagels]

Zitat:

Du weisst aber genau wie ZIP funktioniert? Respekt!

Dumme, respektlose Sprüche bitte unterlassen - danke.

Zitat:

...da kann man dir nicht helfen. Schade. Du redest über Dinge die noch nie ausprobiert hast... alles Hörensagen.

Woher willst du wissen, ob ich das noch nie ausprobiert habe? Soweit ich weiß habe ich darüber noch nie ein Wort verloren.
Es ist schade, wie hier einem Worte in den Mund gelegt werden, die man niemals geschrieben hat.

Zitat:

Irgendwelchen Quatsch mit ZIP-Dateien umkopieren dagegen... mal ehrlich, das ist doch ein Witz oder?

Jeder soll so arbeiten wie er es für richtig hält. Und auf Verrecken jedem Versionskontrollsysteme anbieten zu wollen wird langsam auch lächerlich.

[Sherlock]

Zitat:

Zitat von SneakyBagels (Beitrag 1372510)

Zitat:

Du weisst aber genau wie ZIP funktioniert? Respekt!

Dumme, respektlose Sprüche bitte unterlassen - danke.

Damit ist das Thema für mich erledigt.

Sherlock

[stahli]

Bleibt doch wieder auf einer sachlichen Ebene. Sonst schaukelt sich das wieder sinnlos auf.

Ich habe SVN und GIT mal versucht, aber kam damit nicht klar.
Ich war einfach zu unsicher, was die Software da genau macht und einige Male war da nur noch Müll in den Versionen.

Sicher lag das an mir, aber mit Zips (incl. Zeitstempel im Dateinamen) komme ich als Einzelentwickler besser klar.

Im Team als Nutzer eines betreuten Kontrollsystems sähe das sicher anders aus.

[Luckie]

Etwas mehr Toleranz bitte und zwar auf beiden Seiten. Achtet auf der einen Seite bitte auf eure Wortwahl und Ausdrucksweise und auf der anderen Seite, nehmt nicht alles gleich so persönlich. Dann klappt das auch mit einer sachlichen Diskussion.

[SneakyBagels]

Zitat:

Bleibt doch wieder auf einer sachlichen Ebene. Sonst schaukelt sich das wieder sinnlos auf.

Ich habe SVN und GIT mal versucht, aber kam damit nicht klar.
Ich war einfach zu unsicher, was die Software da genau macht und einige Male war da nur noch Müll in den Versionen.

Sicher lag das an mir, aber mit Zips (incl. Zeitstempel im Dateinamen) komme ich als Einzelentwickler besser klar.

Im Team als Nutzer eines betreuten Kontrollsystems sähe das sicher anders aus.

Endlich mal einer der alt eingesessenen Hasen hier im Forum, der "gegen" Versionskontrollsysteme ist und Zips bevorzugt.

[DeddyH]

Und das sagt genau was aus?

[SneakyBagels]

Das sagt aus, dass es auch professionelle Entwickler gibt denen ihr Code wichtig ist, die trotzdem keine Versionskontrolle benutzen sondern ganz normale Archive.
Somit wäre das Argument, dass den Leuten die Archive nutzen der Code nicht wichtig sei, aus dem Weg geräumt.

[DeddyH]

Man muss ja kein Versionskontrollsystem nutzen, aber wer das einmal getan (und begriffen) hat, der möchte es nicht mehr missen. Ich wüsste zumindest nicht, wie ich in einer Sammlung von Zip-Archiven übersichtlich herausfinden soll, wann ich welches Feature eingeführt habe. Bei einem Versionskontrollsystem schreibe ich das einfach als Kommentar beim Commit hinein und finde das in der Übersicht schnell wieder. Wer ernsthaft in einem Team arbeitet, kommt wohl ohnehin nicht drum herum, sich mit der Materie zu beschäftigen.

[4dk2]

Ich bin sozusagen auch Solo Entwickler, nutze GIT hauptsächlich lokal, und pushe im Prinzip nur zum server als Backup.
Vorher hab ich SVN benutzt, aber ich finde mergde und Versions switchen ist wesentlich einfacher bei GIT(aber mit GUI).

Warum nutze ich Versionierung?
-Hauptgrund ist, das wir über 40 Maschinen mit teilweise stark unterschiedlichen Software Versionen haben (aber das selbe Programm). Tritt irgendwas auf,
kann ich mit einem Doppel-Klick auf Version x.y wechseln, und direkt nach dem Fehler suchen. Ein Doppel-Klick!
Was bei mir irgendwann wenn Zeit ist auf der Agenda steht, ist, habe mal gelesen das man auch Zwei Repos verknüfen kann.
Beispiel: Ein Datenbank Treiber REPO(A) und eine DB Anwendungs REPO(B), die A nutzt.


Ich glaube die "nichtnutzung" von Versionierung, hängt teilweise aber auch mit den Programmen zur Verwaltung der Versionierung zusammen.
Meine absolute Nr. 1 ist SourceTree.
Ist sehr übersichtlich und schnellen Zugriff auf das nötigste.

[Uwe Raabe]

Zitat:

Zitat von SneakyBagels (Beitrag 1372520)

Endlich mal einer der alt eingesessenen Hasen hier im Forum, der "gegen" Versionskontrollsysteme ist und Zips bevorzugt.

Das ist offenbar die übliche Ausnahme von der Regel :)

Ich habe früher auch ZIPs verwendet - und einfache Kopien von Verzeichnissen. Früher - das heißt: als Turbo Pascal 4 unter DOS gerade aktuell war. Dann kam RCS - Ende von Zip/Copy! :feuerchen:

Heute ist Mercurial mein bevorzugtes System. Das Einrichten eines Repos ist eine Sache von Sekunden und das Handling in der Workbench von TortoiseHG ist sowas von simpel und komfortabel, da kommt kein Copy oder Zip mit.

Ich bedauere jeden, der diese Stufe der Erleuchtung noch nicht erreicht hat. :idea:

[SneakyBagels]

Es ist ja nicht so, als ob ich nur Kritik übe. Ich habe schon alle möglichen GUI-Clients ausprobiert und bin nun zum Testen bei SourceTree mit Git hängen geblieben.
Was mir sofort aufgefallen ist: ich kann keine Daten in ein Verzeichnis pushen, welches Buchstaben wie é enthält. Daraus macht SourceTree dann é und legt dementsprechend auch ein Verzeichnis an.

Ist der Bug bekannt, dass SourceTree nicht mir speziellen Buchstaben klar kommt?

[Fritzew]

Welche Sourcetree Version, welches Windows und wo pusht Du hin?
Habe seit Jahren keine Probleme damit gesehen

[SneakyBagels]

Aktuellste Version.

Ich pushe einfach nur auf ein Verzeichnis auf meinem Netzlaufwerk N:\GitTest\Dév

[Fritzew]

Ok, auch auf die Gefahr hin pingelig zu wirken, wo siehst Du diese Verzeichnisse? In Souretree? Im Explorer ?
Wenn Du das Repository in ein anderes lokales Verzeichnis auscheckst wie sehen dann die Ordner im Explorer aus?

[BrightAngel]

Huhu 8-)

Lasst mich auch mal noch ein paar Argumente in den Raum werfen, um diesen konstruktiven Diskurs am Leben zu halten :roll:

Ich würde mich da auch niemals bekriegen deswegen; jeder so, wie es für sie oder ihn läuft.
Aber: Ich würde niemals Code in einer Gruppe oder Team schreiben wollen, bei dem Code über Zips oder andere Archivtypen mit Datumsstempel gemanaged werden aus dem einfachen Grund: Versionskonflikte bei Kolaboration! Und wer bei mir ins Team will und sagt, dass er oder sie noch nie mit irgendeinem Versionierungsprogramm zumindest auseinander gesetzt hat, der muss erstmal in die Ecke und bekommt einen Erklärbär nebendran gesetzt :D

Die Informatik ist in den letzten Jahrzehnten einem Wandel zum Teamplay zum Opfer gefallen :twisted:. Wer den Luxus genießt ein kleines, handliches Projekt sein eigen nennen zu dürfen, das komplett ohne versionierte Abhängigkeiten auskommt, dem gönne ich das sehr und in diesem Rahmen dürfte das Archivgeschubse wirklich funktionieren! Aber Teamplay ist was Schönes (alle, die in einem eingespielten, harmonischen Team arbeiten dürfen, werden mir da vermutlich freudig nickend zustimmen :-D)! Große Projekte kann man nur im Team stemmen und dabei können großartige Dinge und Freundschaften entstehen. Klar, das läuft nicht immer rund und manchmal hat man die ein oder andere Teambremse mit an Bord, aber selbst das lässt sich oft gut lösen. Für mich ist Git, Mercurial, SVN quasi das Sinnbild für guten Teamgeist!

Auch wenn submodules von Git den ein oder anderen Quirk haben, so helfen auch sie beim Abhängigkeiten einbauen: Dadurch das die Daten des Submodules niemals im eigenen Repository landen, sondern nur auf einen ganz bestimmen Versionsstand verwiesen wird, ergibt sich mit diesem Wissen eine ganz neue Restriktive; man wird allein dadurch schon gezwungen ordentlich zu arbeiten und man modularisiert dadurch sprachunabhängig und die Trennung der Module bleibt trotz Versionierung und normaler Sicht im ausgecheckten Ordner erhalten! 8-)

Ich hoffe, ich konnte das ein oder andere Argument liefern, das das Herz des einen oder anderen verbissen Gegners von Versionierungstools ein wenig erweichen konnte: Gib der automatisierten Versionierung eine Chance in deinem Workflow zu existieren! :) Und wenn du graphische Tools nicht magst, benutz die Kommandozeile: git pull [--rebase], git log, git add, git commit --interactive, git commit -a, git push, seien als Beispiel deine Freunde. Und wenn du mal gar nicht mehr weiter weißt: Cheatsheets für alle :D!

Brighty :)

[himitsu]

Zitat:

Zitat von SneakyBagels (Beitrag 1372557)

Ist der Bug bekannt, dass SourceTree nicht mir speziellen Buchstaben klar kommt?

Nja, so halb kommt es damit ja klar, denn é ist ja das UTF-8 vom Unicode-é.
Nur beim Runterladen geht dann wohl was beim decodieen schief, aber eigentlich würde ich denken, dass so ein Bug schon lange aufgefallen und behoben sein sollte.

Ich bin bei Tortoise hängen geblieben.
Beruflich über SVN da reingerutscht und daheim für GIT und SVN installiert, da man auch ab und an mal irgendwas mit GIT runterladen möchte/müsste.

[SneakyBagels]

Mit dem Fachchinesisch kann ich nix anfangen.

Ich mache einen initialen Commit meines lokalen Quellverzeichnisses.
Das klone ich jetzt auf mein Netzlaufwerk. Im Quellverzeichnis-Repository füge ich als Remote das Repository vom Netzlaufwerk hinzu.

Jetzt füge ich im Quellverzeichnis eine neue Datei ein und commite die Änderungen.
SourceTree zeigt mir nun oben links bei "Push" eine blaue 1 an. Soweit so gut.
Jetzt klicke ich auf Push. Es kommt ein Dialog mit einer Liste. Dort mache ich einen Haken bei meinem master branch oder wie auch immer das heißt.
Ich klick auf OK, es lädt ein bisschen und werkelt rum, und diese eine Datei befindet sich danach nicht auf meinem Netzlaufwerk. Nichts wurde geklont.

[Lemmy]

Zitat:

Zitat von SneakyBagels (Beitrag 1372567)

Nichts wurde geklont.

so mal aus der Hüfte geschossen: Mal auf dem klon ein Pull gemacht? Wenn Du dein Zeugs wegzippst, dann ist die neue Datei doch auch nicht auf deinem "Klon" vorhanden - du musst da ja auch erst das zipfile wieder entpacken...

[SneakyBagels]

Pull funktioniert zwar aber die Verzeichnisse sind nie gleich und das ist ja der Sinn den ich dahinter suche.
Denn wenn ich Dinge commite (lokal) dann würde ich das ganze Repo gerne auf eine andere Festplatte spiegeln damit ich immer eine Sicherung davon habe.

Rechtsklick => Kopieren, Rechtsklick => einfügen ist da wesentlich einfacher ;)

[jfheins]

Ich glaube, du musst deine Erwartungen noch geringfügig anpassen.

In deinem Quellverzeichnisses hast du ja einen .git Ordner ("das Repo") und die eigentlichen Dateien (Arbeitskopie/working copy). Als push-Ziel solltest du ausschließlich bare-Repositories benutzen - das sind Repos ohne working copy, die quasi auf das .git Verzeichnis beschränkt sind.

Wenn du den push ausführst, wirst du darin nicht einfach so die neue Datei finden. Die ist unter /objects/ irgendwo unter dem Hash abgelegt. Da sollte man erst mal nichts drin verändern.
Du kannst jetzt aber jederzeit und überall (wo du git hast) wieder einen neuen clone anlegen, der wieder eine Arbeitskopie enthält.

[SneakyBagels]

Bedeutet das, dass das Push-Feature gar nicht darauf ausgelegt ist mein komplettes Projektverzeichnis in ein anderes Verzeichnis zu spiegeln denn es kopiert nur Änderungen im .git-Verzeichnis?

[Fritzew]

Zitat:

Zitat von SneakyBagels (Beitrag 1372583)

Bedeutet das, dass das Push-Feature gar nicht darauf ausgelegt ist mein komplettes Projektverzeichnis in ein anderes Verzeichnis zu spiegeln denn es kopiert nur Änderungen im .git-Verzeichnis?

Ja klar, stell Dir mal vor Dein Push Ziel ist auf dem Rechner eines Kollegen, Du Pushst dahin und seine Änderungen sind wo?

[Lemmy]

Zitat:

Zitat von SneakyBagels (Beitrag 1372583)

Bedeutet das, dass das Push-Feature gar nicht darauf ausgelegt ist mein komplettes Projektverzeichnis in ein anderes Verzeichnis zu spiegeln denn es kopiert nur Änderungen im .git-Verzeichnis?

nein. Wenn Du ein Verzeichnis in eine Zipdatei verpackst sind deine anderen Kopien des Projekts ja auch nicht automatisch angepasst. Du musst die ZipDatei dort erst wieder entpacken. Im Grunde das selbe Prinzip

Und wie jfheins schreibt hast Du gerade als Einzelentwickler dem es primär um die Sicherung seiner Sourcen geht ein bare-Repository auf einem anderen REchner, das quasi als Ablage funktioniert.

[hstreicher]

Mal etwas in der Mottenkiste gewühlt:

es gab durchaus auch eine Sourcecode Verwaltungssoftware von Borland , Star Team wenn ich mich richtig erinnere ,
und von den Jedis gab/gibt es Jedi VCS

mfg Hannes

[Bernhard Geyer]

Zitat:

Zitat von hstreicher (Beitrag 1372603)

Mal etwas in der Mottenkiste gewühlt:

es gab durchaus auch eine Sourcecode Verwaltungssoftware von Borland , Star Team wenn ich mich richtig erinnere ,
und von den Jedis gab/gibt es Jedi VCS

mfg Hannes

Star Team war/ist doch kein Quellcodeverwaltungstool! Es hat evtl. Schnittstellen dorthin, aber der eigentliche Kern dieser SW liegt woanders.

[Uwe Raabe]

Zitat:

Zitat von hstreicher (Beitrag 1372603)

es gab durchaus auch eine Sourcecode Verwaltungssoftware von Borland , Star Team wenn ich mich richtig erinnere ,

Nein, das hieß TeamSource und war z.B. mit auf der damaligen Delphi 5 CD.