[GIT] Welche Version bearbeite ich gerade in Delphi?

[ggscholz]

Hallo zusammen,
in diesem Forum lese ich gerne mit und häufig finde ich hier Antworten oder Ideen, wenn ich nicht weiter komme. Das ist hier schon eine tolle Leistung!! D7 war mein Start in die Programierwelt und der Reiz, sich sein eigenes Programm mit Komponenten und ein paar Zeilen Code zusammen zu Klicken, hat dazu geführt, das es alles wunderbar funktioniert, aber vorzeigbarer Code ist das nicht. Das werde ich ändern müssen, da ich irgendwann die Programme an einen Nachfolger übergeben werde.

Ich habe mir dazu GIT und Sourcetree eingerichtet (ja, ich gebe zu, ich liebe Knöpfe, die Komandozeile ist für mich nichts).

Ich möchte den bisherigen Stand sicheren und für kleinere Fixes bearbeiten und ausliefern können, gleichzeitig werde ich aber die Version 2.0 in einem neuen Branche auf Basis der bisherigen Version umschreiben und an manchen Stellen auch neu schreiben.

Kann ich in Delphi (Berlin) erkennen , mit welchem Branche ich gerade Arbeite?

Beste Grüße
Gerd

[joachimd]

Zitat:

Zitat von ggscholz (Beitrag 1507628)

Ich habe mir dazu GIT und Sourcetree eingerichtet (ja, ich gebe zu, ich liebe Knöpfe, die Komandozeile ist für mich nichts).

Ich möchte den bisherigen Stand sicheren und für kleinere Fixes bearbeiten und ausliefern können, gleichzeitig werde ich aber die Version 2.0 in einem neuen Branche auf Basis der bisherigen Version umschreiben und an manchen Stellen auch neu schreiben.

Kann ich in Delphi (Berlin) erkennen , mit welchem Branche ich gerade Arbeite?

In Delphi kann ich Dir nicht sagen, aber in Sourcetree siehst Du es, ebenso auf der Kommandozeile über git status.

[Der schöne Günther]

Ich habe zwar nichts gegen die Kommandozeile aber ja, es ist großartig wenn man grafisch vor sich sieht, welche Änderungen hintereinander kommen, wo sich etwas abzweigt -

Das gibt es in Delphi so leider nicht. Aber mit Alt+Tab kann man ja immer schnell zwischen Delphi-IDE und z.B. SourceTree (nicht mein Geschmack) wechseln.

Hier das gleiche nochmal in der englischen Delphi-Praxis, mit vielen Bildern:

https://en.delphipraxis.net/topic/55...#comment-48055

[stahli]

etwas OT: Schau Dir evtl. mal GitKraken an. Finde ich eine tolle Git-Gui und damit komme sogar ich teilweise klar. ;-)

[himitsu]

Der integrierte History-Viewer und die ContextMenüs zeigen den Branchname nicht an.

Du kannst maximal an der Historie (Kommentar/Hash der letzten Commits erahnen wo du grade bist).




Oder in der Projektverhaltung zum Explorer springen und dort im Kontextmenü des anderen Git-Tools nachlesen.
Oben ins Verzeichnis-Edit des Explorers darf man auch

Delphi-Quellcode:

cmd[enter]

eingeben (oder Dergleichen).




Es wäre aber bestimmt nicht sehr schwer sich eine IDE-Erweiterung zu schreiben, welche im Kontextmenü des Code-Editors und der Projektverwaltung ein MenüItem einfügt, mit dem Mamen des Branches.
Oder vieleicht sogar in den History-Viewer ein Label/Edit einzufügen. (das wird schon schwerer werden)

[Uwe Raabe]

Ich sehe ja keinen wirklichen Vorteil in der IDE-Integration, wenn ich für die meisten Aufgaben eh einen externen Client verwenden muss. Was man in der IDE machen kann ist ja echt nur wenig.

Der Wechsel zu meinem sowieso laufenden Fork-Client geht mindestens genauso schnell wie das Umschalten in der IDE und das Ergebnis wie auch die Möglichkeiten sind deutlich besser. Geistig umschalten was die Bedienung betrifft muss ich dann auch nicht erst.

[Incocnito]

Hi,

manchmal sind die einfachsten und augenscheinlich dümmsten Ideen die besten, daher mal aus dem Nähkästchen geplaudert:
Bei der Firma checken wir die verschiedenen Branche jeweils in eigene Verzeichnisse aus.
So viel Platz nimmt das ja meistens gar nicht weg, wenn man dcu und generierte EXE wo anders
hin packt und so viele Branche hat man meistens nicht. So erkennt man einigermaßen wo man
gerade ist. Ich komme damit ganz gut klar.

LG Incocnito

[Sherlock]

Was ist "auschecken" im Git Kontext?

Sherlock

[himitsu]

viele Kopieen des Clones
oder git worktree

[Sherlock]

Es hört sich für mich nach einem Versuch an, althergebrachte SVN Manierismen am Leben zu erhalten, auf Teufel komm raus.

Sherlock

[Frickler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1507642)

Der Wechsel zu meinem sowieso laufenden Fork-Client geht mindestens genauso schnell wie das Umschalten in der IDE und das Ergebnis wie auch die Möglichkeiten sind deutlich besser. Geistig umschalten was die Bedienung betrifft muss ich dann auch nicht erst.

Die nicht eingecheckten Änderungen ("Lokale Sicherung") sieht man da auch?

[Uwe Raabe]

Zitat:

Zitat von Frickler (Beitrag 1507732)

Die nicht eingecheckten Änderungen ("Lokale Sicherung") sieht man da auch?

Was genau verstehst du darunter? Die Dateien die seit dem letzten Commit verändert, hinzugefügt oder gelöscht bzw. umbenannt wurde?

[jobo]

Auch wenn Du von der Kommandozeile nicht überzeugt bist.
>git status
liefert Dir gute Informationen. Nicht nur wo Du gerade bist, auch was da "lose" ist.
(Du musst natürlich mit der Kommandozeile im richtigen Verzeichnis sein.
Mglw. kann man den Aufruf auch als Werkzeug in die IDE integrieren.

[himitsu]

Tool > Tool konfigurieren > Hinzufügen


Also das Erste läuft schonmal. (das Zweite sollte auch gehn, weil "gleich", aber geht nicht)
Nur "git status" im richtigen Verzeichnis und dass es am Ende auch noch lange genug offen bleibt (nicht sofort wieder zu geht) ........ :freak:

Es wäre auch zu einfach, wenn man im "Arbeitsverzeichnis" ebenfalls Makros verwenden könnte. :roll:

Vor bash.exe oder git-bash.exe das Arbeitsverzeichnis zu ändern, funktioniert aber eh nicht.
(ihnen kann man nur den Pfad als Parameter mitgeben, aber Pfad und Befehl "git status" gleichzeitig ging auch nicht)




Titel: GIT @ Projekt
Programm: C:\Program Files\Git\git-bash.exe
Parameter: --cd=$PATH($PROJECT)

Titel: GIT @ Current File
Programm: C:\Program Files\Git\git-bash.exe
Parameter: --cd=$PATH($EDNAME)

Titel: GIT Status @ Project
Programm: C:\Program Files\Git\bin\bash.exe
Parameter: -c git status $PATH($PROJECT)

Titel: GIT Status @ Project
Programm: CMD
Parameter: /c "C:\Program Files\Git\bin\bash.exe" -c git status $PATH($PROJECT)
Parameter: /c "C:\Program Files\Git\bin\bash.exe" -c git -C $PATH($PROJECT) status
Parameter: /c "C:\Program Files\Git\bin\bash.exe" -c git --git-dir=$PATH($PROJECT) status


Titel: Test 1 und 2
Programm: CMD
Parameter: /k echo PROMPT=$PROMPT(hallo) & echo COL=$COL & echo ROW=$ROW & echo CURTOKEN=$CURTOKEN & echo PATH:EDNAME=$PATH($EDNAME) & echo NAME:EDNAME=$NAME($EDNAME) & echo NAMEONLY:EDNAME=$NAMEONLY($EDNAME) & echo EDNAME=$EDNAME
Parameter: /k echo EDNAME=$EDNAME & echo PROJECT=$PROJECT & echo EXENAME=$EXENAME & echo HOSTNAME=$HOSTNAME & echo PARAMS=$PARAMS & echo TDW=$TDW

[Sherlock]

Ich halte es für ziemliches Gefrickel einen Mischbetrieb von CVS und händischen "Sicherungskopien" zu betreiben. Zumindest ist das nicht "best practice". Locale commits landen erst nach einem Push auf dem Server, sie stören also keinen. Wer aus kosmetischen Gründen die Anzahl der Commits gering halten möchte, kann diese auch mit rebase zusammen fassen, aber für mich hat das schon ein Geschmäckle, aber ich komme auch von der "you don't need more than change then commit/pull/merge/push to work" Fraktion.

Sherlock

[himitsu]

Nja, spaßig wird es mit den ganzen Forks, wenn die zu sehr auseinandergelaufen sind und man sich ausversehn am anderen Ende wiederfindet.

[Frickler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1507742)

Zitat:

Zitat von Frickler (Beitrag 1507732)

Die nicht eingecheckten Änderungen ("Lokale Sicherung") sieht man da auch?

Was genau verstehst du darunter? Die Dateien die seit dem letzten Commit verändert, hinzugefügt oder gelöscht bzw. umbenannt wurde?

Naja, was die IDE anzeigt unter "Historie", oberhalb von den Einträgen, die ausm VCS kommen. Ich check doch nicht jeden geänderten Buchstaben sofort ein...

[Uwe Raabe]

Zitat:

Zitat von Frickler (Beitrag 1507815)

Naja, was die IDE anzeigt unter "Historie", oberhalb von den Einträgen, die ausm VCS kommen.

Die Historie ist ja vollkommen unabhängig vom verwendeten Git-Client und bleibt somit ja erhalten.

Da es sich beim _History Ordner um eine Delphi-IDE spezifische Sache handelt, kann natürlich kein externer Git-Client damit etwas anfangen (zumindest kenne ich keinen). Insofern gibt es dort auch diesbezüglich wohl keine Unterschiede.

Ich muss für mich auch gestehen, dass ich die Git-Integration wieder aus der IDE rausgenommen habe, weil ich somit klar zwischen der Lokalen Sicherung und dem Git-Repo unterscheiden kann. In der Realität ist es eben gerade nicht so, dass die lokalen Änderungen immer über den VCS-Änderungen stehen.

[himitsu]

Sobald das GIT-Addon in der IDE ein Git-Repo findet, wird die delphi-eigene Historie doch eh abgeschaltet.
Somit gibt es keine Vermischung von Beidem und im Grunde bräuchte man dann auch keine Git-GUI, welche das anzeigen kann.


Aber wenn es sein muß, dann ließe sich das vom _history bestimmt (auch automatisiert) in git-commits überführen (konvertieren).
* Repo erstellen (falls noch nicht da)
* die aktuelle Dateiversion sichern
* dann nach und nach die Dateien aus diesem Verteichnis in den übergeordneten Ordner kopieren
* und die Änderungen commiten, inkl. der vorher gesicherten Version

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1507817)

Sobald das GIT-Addon in der IDE ein Git-Repo findet, wird die delphi-eigene Historie doch eh abgeschaltet.

Das habe ich aber erst kürzlich ganz anders erlebt. Insbesondere auch, weil dadurch ein weiteres Backupmedium mit anderer Zielsetzung entfallen würde.

<ausprobieren...>

Nee, wird nicht abgeschaltet.

[himitsu]

Hmmm, vielleicht haben sie es geändert?
Mir war nur mehrmals aufgefalen, dass das Verzeichnis leer war, sobald GIT mitspielte.

Ein Problem ist dabei aber, dass hier jede Datei für sich selbst gespeichert wird und es nicht wirklich zusammenhängt.
Man könnte vielleicht noch versuchen über's Datum Dateien für einen "Commit" zusammenzusassen (jede Datei wie einen eigenen Commit im VCS-Client anzuzeigen wäre wohl bissl unübersichtlich)

[joachimd]

__history sollte wie andere Temporär-Dateien eh grundsätzlich auf die ignore-Liste gesetzt werden. Damit kann keiner wirklich was anfangen. Lieber viele Commits mit sinnvollen Kommentaren.

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1507749)

Nur "git status" im richtigen Verzeichnis und dass es am Ende auch noch lange genug offen bleibt (nicht sofort wieder zu geht) ........ :freak:

Was Du schreibst, klingt etwas seltsam für micht, aber ich kann es nicht prüfen. Hätte gedacht, man kann einfach ein Programm oder Skript aufrufen.
Ein:
>Pause
Verhindert vielleicht das Zugehen.

Bash oder andere sollten eigentlich unnötig sein, der Befehl git müsste reichen.

[himitsu]

ja klar, eine Batchdatei, die mehr macht und am Ende wartet ... geht bestimmt

per seh sollte es eigentlich auch direkt gehen
* GIT direkt aufrufen, hält am Ende natürlich nicht an
* aber CMD oder BASH so aufrufen, dass sie nach Ausführen eines Befehls sich nicht schließenen
** ihnen außerdem das Arbeitsverzeichnis mitzugeben
** und ihnen einen Befehl (git status) mitzugeben, der sofort ausgeführt wird

Die CMD/BASH zu starten, und ihr Parameter oder vorher per Arbeitsverzeichnis deren Start Arbeitsverzeichnis mitzugeben,
bzw. dem GIT beim Start das Arbeitsverzeichnis mitzugeben ...
hier hängt es teilweise (bzw. es geht nicht bei jeder Variante)


Man kann mehrere Befehle der CMD/BASH geben und am Ende ein PAUSE machen lassen
oder eben via /C vs. /K sagen, dass sie am Ende offen bleiben sollen (weitere Befehle eingebbar)

[freimatz]

Ich selber benutze git bewusst nur ohne die Delphi-IDE (SoC).
So habe ich den Überblick was genau ich einchecke und kann noch Daten reparieren die Delphi mit kaputt gemacht hat (meist dfm, ab und zu auch dpr, dpk und dproj). Als Client verwende ich TortoiseGit (aufgrund der für mich besten Baumdarstellung), selten noch Kommandozeile.

[ggscholz]

Danke für die ausführlichen Hinweise,

Zitat:

Zitat von Uwe Raabe (Beitrag 1507642)

Ich sehe ja keinen wirklichen Vorteil in der IDE-Integration, wenn ich für die meisten Aufgaben eh einen externen Client verwenden muss. Was man in der IDE machen kann ist ja echt nur wenig.Der Wechsel zu meinem sowieso laufenden Fork-Client geht mindestens genauso schnell wie das Umschalten in der IDE und das Ergebnis wie auch die Möglichkeiten sind deutlich besser. Geistig umschalten was die Bedienung betrifft muss ich dann auch nicht erst.

Das wird auch mein Weg sein, ALT-TAB ist ja nicht weit weg. Die Frage nach der Sichtbarkeit der aktuellen GIT Version ergab sich aus der in Delphi angebotenen Integration von GIT. Das scheint aber nur ein erster Anfang zu sein, ob jetzt sinnvoll oder nicht. Ich werd's auch nicht weiter nutzen.

Zitat:

Zitat von stahli (Beitrag 1507632)

etwas OT: Schau Dir evtl. mal GitKraken an. Finde ich eine tolle Git-Gui und damit komme sogar ich teilweise klar. ;-)

Zitat:

Zitat von Uwe Raabe (Beitrag 1507642)

Fork-Client.

Zitat:

Zitat von freimatz (Beitrag 1507961)

Als Client verwende ich TortoiseGit (aufgrund der für mich besten Baumdarstellung), selten noch Kommandozeile.

Wie schon anfangs geschrieben, ich brauch GIT nur, um aktuell zwei Versionen zu bearbeiten: die ausgeliefert, wenn da sich irgendein Bedarf ergibt, und die neue Version, die in der Funktion erst mal gleich sein wird, aber mit deutlich überarbeiteten Proceduren und Funktionen. Insofern wird jeder Client reichen, ich muss mich halt in eine einarbeiten. Trotzdem Danke für die Hinweise, ich werde die mir ansehen.

Und in Delphi irgendetwas reinbasteln, was einen GIT Client ersetzt, das werde ich mir definitiv nicht antuen. Ich will meine Programme schreiben.

Beste Grüße Gerd