Meine letzte zwei Projekten kamen noch aus der Zeit wo Menschen freiwillig SVN eingesetzt haben :)
Wenn man aber in den Genuss des lokalen commits bereits gekommen ist, dann wird es kompliziert.
Zum einem hat man einen unbehaglichen Gefühl alles sofort global einzuchecken. Anderseits, gemachten Änderungen länger als ein paar Stunden auf dem Rechner uncommitet zu haben - ist auch be-be-be. Und das wechseln zwischen verschiedenen Versionen - das ist doch einfach geil! Jeder Zeit ohne Risiken und Sorgen, innerhalb von wenigen Sekunden auf die Vorgengenversion oder auf einen anderen Branch wechseln zu können. Und dann wieder zurück zu den aktuellen Anpassungen, ... Klasse!
Also mein Ziel ist - bei mir den GIT als SVN-Client bei einem langlaufenden Projekt einzusetzen. Am besten so, dass die anderen Entwickler, die weiterhin mit SVN-Client arbeiten, nichts von meinen Innovationen mitbekämmen. Also zumindest davon nicht gestört wären.
Default Konfiguration für Windows verbessern
git config --global user.name "Mark Stein"git config --global user.email "m.stein@mosst.de"
# Lange Pfade ermöglichen, komisch dass das kein default Wert bei git ist
git config --system core.longpaths true
# Git soll von den Lineendigs die Hände weglassen, bitte keine Automatismus.
# Insbesondere wenn man auf Windows-Rechnern die Artifakte für Unix bauen will
git config --system core.autocrlf false
Loslegen - Das erste Checkout ala Update ala Fetch ala Pull ala Rebase
Komisch warum ein frisch geborene Entwickler sich am Anfang seines Versionierungsweges etwas verarscht fühlt. Da, allein für den Vorgang "Hol mir bitte eine Version von dem Server" zig verschiedene Mechanismen existieren.
Checkout - in SVN-Welt holt man sich dabei einen Code-Stand von dem Server herunter.
Checkout - in GIT-Welt wechselt man hiermit zwischen Versionen (Branch ist auch eine Version).
Update- nur in SVN-Welt, damit wird aktuelle Versionsstrang (trunk, branch-xy) auf die aktuellste oder angegebene Version von dem Server aktualisiert.
Fetch - nur in GIT-Welt, aktualisiert alle (oder ausgewählte) remote Versionstränge. Wichtig: lokale Versionstränge (Branches) werden davon nicht beeinflusst.
Pull - lokale Branches werden auf die Versionsstände von gemappten remote Branches gebracht. Tipp: mit git branch -vv kann dieses Mapping angeschaut werden, allerdings nicht bei SVN Repositories :( Danach suche ich noch.
Rebase -
... in Arbeit ...
Angedachte Themen:
* Arbeit mit SVN Branches: Wechsel, Merging
* Wechselwirkung mit einem weiterem Remote-Repository z.B. auf dem USB-Stick
Keine Kommentare:
Kommentar veröffentlichen