Anfänger, Hallo und ein paar Fragen.. ;-)
-
@Robertop sagte in Anfänger, Hallo und ein paar Fragen..
:Wie macht ihr in C++ die Versionsverwaltung ?
Git + TortoiseGit
Gerade mit TortoiseGit ist ein einfacher Einstieg möglich. Man muss einfach ein paar Grundbegriffe lernen (Pull, Push, Commit,...) und schon kommt man damit zurecht.
-
Danke für die Antworten...
Ich finde es sehr umständlich, dass man da immer so kompliziert umsteigen muss zwischen der Graphischen Ansicht des Fensters (Buttons usw)und dem Quellcode des Fensters.
Ist das bei den anderen Bibliotheken einfacher ?
Warum kann man nicht Grafik und Quellcode gleichzeitig sehen?
-
@Quiche-Lorraine sagte in Anfänger, Hallo und ein paar Fragen..
:TortoiseGit
Da muss ich mich erst einlesen..
Kann man das Git auch auf der eigenen Platte verwenden oder geht das dann nur immer mit einer Cloud ?
-
Hallo @Robertop,
ich arbeite gerne mit C++ und nutze für das GUI Qt. Da habe ich einen Designer für die grafische Oberflächengestaltung. Den Code habe ich in der Entwicklungsumgebung (unter Windows VS, unter Linux den Qt Creator) und den Qt Designer habe ich bei Bedarf sofort gestartet oder noch geöffnet. Wenn ich z.B. an einen Dialog etwas ändern möchte, mach ich das im Designer, lass den Code neu generieren und nutze in in der IDE.
Bedenke aber bitte, dass C++ schon etwas beherrscht werden muss, egal welche Bibliotheken man benutzt. Besonder muss man das objektorientierte Paradigma beherrschen. M.m.n. das größte Problem bei einem Umstieg von einer prozeduralen bzw. funktionalen Sprache zu einer objektorientierten Sprache wie C++. Insbesonders Umsteiger von C zu C++ haben es besonders schwer, der C++ Compiler verarbeitet C ohne Mücken.
-
Hallo @Robertop,
ich nutze Git ohne Cloud, also nur lokal. Ich sichere meine Versionsständ z.B. auf einem Stick.
Ich arbeite aber auch nicht mit mehreren Leuten an einem Projekt. Dann würde ich GitHub oder Ähnliches vorschlagen.
-
@Robertop sagte in Anfänger, Hallo und ein paar Fragen..
:Kann man das Git auch auf der eigenen Platte verwenden oder geht das dann nur immer mit einer Cloud ?
Das ist vollkommen egal. Erst einmal liegt der Code und seine Versionsgeschichte bei dir. Das kann dann mit einer oder mehreren Remotes verknüpft sein, wohin dann synchronisiert wird. Man kann aber auch keine Remotes haben, wenn man nicht will. Und selbst wenn, dann kann eine Remote jede beliebige URL sein, inklusive einem anderen Verzeichnis auf deinem Computer.
Die meisten Leute nutzen aber Remotes auf einem anderen Computer (oder gehosted auf github & Co.), denn neben Versionierung ist git ja hauptsächlich ein Werkzeug zum geteilten Arbeiten, und da ist ein zentral erreichbarer Ort zum Teilen ganz praktisch.
-
Dieser Beitrag wurde gelöscht!
-
@Helmut-Jakoby sagte in Anfänger, Hallo und ein paar Fragen..
:Hallo @Robertop,
ich nutze Git ohne Cloud, also nur lokal. Ich sichere meine Versionsständ z.B. auf einem Stick.
Ich arbeite aber auch nicht mit mehreren Leuten an einem Projekt. Dann würde ich GitHub oder Ähnliches vorschlagen.Ich habe mal GIT probiert und Locale Repository angelegt (im Ordner vom Projekt)
Habe Branches angelegt--> OK
Wenn ich aber Commit erstellen will und auf Push gehe , kann ich nur GitHub und Azure DevOps aussuchen.
Auch sind im GIT-Fenster, die Befehle: Pull, Push usw., alle nur hell grau .Ganz blicke ich da noch nicht durch
-
Ein Repository hat immer ein Origin, von dem es geklont oder in dem es erzeugt worden ist. Du kannst ein Repository nur dann pushen, wenn es nicht das (der?) Origin ist.
Generell gilt:- commit => lokale Änderungen in lokales Repository übernehmen
- push => Lokales Repository in das Origin übertragen (ohne Origin nicht möglich)
- pull => Lokales Repository erzeugen, indem es von Origin geklont wird (push jetzt möglich, weil Origin bekannt)
-
Wenn ich für mich nur eine einfache Version Verwaltung will, was muss ich dafür machen?
(z.B. fehlgeschlagene Änderungen, rückgängig zu machen )Lege ich dann nur immer neue Branches an ?
-
Du commitest einfach. Du kannst hin- und herspringen zwischen verschiedenen Ständen, wie du möchtest. Es kann dabei ganz praktisch sein, verschiedene Branches zu haben, z.B. einen Hauptzweig, in den nur fertige Dinge kommen, und Entwicklungsbranches, in denen du neue Dinge entwickelst, die dann wieder in den Hauptzweig wandern, wenn sie fertig sind.
Fetch, Push, Pull, Origins, Remotes, etc., das ist alles nur dazu da, deinen lokalen Stand mit dem Stand eines anderen Repositories zu synchronisieren. Wenn du rein lokal arbeitest, brauchst du das nicht. Dadurch ändert sich die grundlegende Arbeitsweise nicht, außer das eben diese Synchronisierungsschritte ersatzlos entfallen.
Für rein lokale Versionsverwaltung brauchst du nur die Kommandos, die sich auf das Arbeiten mit Commits und Branches beziehen. Hauptsächlich werden das commit (inklusive add, remove, etc.), branch, merge, checkout und rebase sein.
-
Konkret zum Rückgängigmachen von Änderungen gibt es zwei Möglichkeiten (es gibt natürlich noch viel mehr, aber dies sind die beiden häufigsten), je nachdem, wie du die Lage einschätzt:
- Du kannst einen Branch auf einen von dir gewählten Commit zurück setzen. Dann ist alles nach diesem Commit quasi weg und du kannst wieder an der Stelle dieses neuen Commits neu anfangen (Es ist natürlich nicht wirklich "weg". In Git geht quasi nie etwas unwiederbringlich verloren. Dein Branch verhält sich bloß so, als wäre er wieder auf dem alten Stand). Das ist ganz praktisch, wenn du merkst, dass der letzte Commit, den du gemacht hast, Mist war (zum Beispiel ein Merge, mit dem du unzufrieden bist). Du kannst dabei sogar wählen, ob die lokalen Dateien beim Reset in den Zustand des gewählten Commits versetzt werden sollen (wenn du alles wegwerfen willst) oder auf dem Stand vor dem Reset verbleiben sollen (wenn du nur das Committen an sich rückgängig machen möchtest, aber mit dem Inhalt der Dateien ganz zufrieden warst). Außerdem geht das nur, solange die Änderungen noch nicht mit einer Remote synchronisiert wurden. Aber das ist bei dir ja sowieso nicht der Fall.
- Du kannst einen Commit rückgängig machen. Das erzeugt einen neuen Commit, der alle Änderungen des gewählten Commits umkehrt (Ein Commit ist so etwas wie eine Sammlung von Änderungen relativ zum vorherigen Stand, das kann man daher auch einfach umkehren). Das ist nützlich, wenn das Problem schon etwas her ist und sich konkret auf 1-2 Commits bezieht. Außerdem ist es die saubere Art und Weise, Dinge rückgängig zu machen, die schon an eine Remote veröffentlicht wurden. Achtung: Einen Mergecommit rückgängig zu machen, ist nicht so einfach und bedarf entweder eines tieferen Verständnisses oder einer Anleitung!
Strategie 2 kann natürlich nur aufgehen, wenn deine Commits inhaltlich sinnvoll strukturiert sind. So etwas wie "Schreibe Funktion ABC um, so dass sie Bibliothek XYZ benutzt". Und absolut nichts anderes ist in dem Commit, was nicht dazu gehört.Ganz schlecht ist offensichtlich so etwas wie "Stand am Freitag um 17 Uhr", weil das dann keine sinnvolle codetechnische Einheit ist, so dass dann auch eventuelle Probleme in diesem Commit nicht einzeln angegangen werden können.
Ich empfehle auch dringend dies, bevor du dir schlechte Angewohnheiten zulegst. In ein paar Jahren wirst du mir dafür danken:
https://cbea.ms/git-commit/
-
@DocShoe sagte in Anfänger, Hallo und ein paar Fragen..
:Ein Repository hat immer ein Origin, von dem es geklont oder in dem es erzeugt worden ist. Du kannst ein Repository nur dann pushen, wenn es nicht das (der?) Origin ist.
Generell gilt:- commit => lokale Änderungen in lokales Repository übernehmen
- push => Lokales Repository in das Origin übertragen (ohne Origin nicht möglich)
- pull => Lokales Repository erzeugen, indem es von Origin geklont wird (push jetzt möglich, weil Origin bekann)
Ersetze Origin durch remote, wobei Origin per Konvention der default remote ist.
-
@SeppJ sagte in Anfänger, Hallo und ein paar Fragen..
:(Es ist natürlich nicht wirklich "weg". In Git geht quasi nie etwas unwiederbringlich verloren.
Wenn die garbage collection zuschlägt sind die commits (außer sie werden noch woanders referenziert) doch weg.
-
Hallo @Robertop,
um Git zu nutzen, musst Du Dich mit dem Konzept und den einzelnen "Ausdrücken" vertraut machen. Git ist im Netz umfangreich erklärt.https://git-scm.com/book/de/v2/Erste-Schritte-Was-ist-Versionsverwaltung%3F
Ich habe mehrere Tage gebraucht, um Git einigermaßen zu beherrschen. Es führt mMn zum Frust, wenn man mit Halbwissen Git benutzt. Ich rate auch davon ab, in der ersten Lernphase ein grafisches Tool zu benutzen. Erst wenn ich Git beherrsche, kann ich ein grafisches Tool effizient einsetzen.
-
@Helmut-Jakoby sagte in Anfänger, Hallo und ein paar Fragen..
:Erst wenn ich Git beherrsche, kann ich ein grafisches Tool effizient einsetzen.
Und immer aufpassen wenn GUIs andere Begriffe nutzen als das cli tool. Revert z.B. ist in Tortoise-Git was anderes als im eigentlichen git.
-
Hallo @Robertop,
hab noch das auf meinem Desktop (kopiert, da der Link ggf. bald nicht mehr verfügbar ist) abgelegt und im den Befehl "git update-git-for-windows" erweitert.
-
Ich glaube ich habe das jetzt mit Commit jetzt geschafft...
Es gibt da auch noch ein Video für Visual Studio 2019
https://www.youtube.com/watch?v=Yfz1EZ_YLhE
Das habe ich mir jetzt drei mal angeschaut.
(Passt zwar nicht ganz zu Visual Studio 2022 aber eine kleine Hilfe)Hier noch ein anderes Video für GitHub (Falls mal einer sucht...)
https://www.youtube.com/watch?v=0jzjz4MZ4ZUIch mache das so:
- ) Git-Repository erstellen, Local und im Projekt Ordner
- ) Programmcode zum Versuch modifizieren
- ) unter: GIT/Commit oder Stash
das Fenster aufmachen und dann sieht man dort die Änderungen.
Ich hatte den Fehler gemacht, dass ich nicht das Plus Zeichen (stagen) ausgewählt hatte (rechts)
Erst dann wird der Button für Commit schwarz und man kann dann commiten.Jetzt habe ich den ersten Commit auf den Master-Branch
Danke für Eure Geduld
-
Kann man das Committen nicht direkt aus VS bewerkstelligen?
