SmartGit Verständnisproblem, 3 Branches

[günni0]

Ich lerne mich gerade in Versionskontrollsysteme ein und nutze dafür SmartGit. Vorher SourceTree. Jetzt aber SmartGit, da es 100% portable und irgendwie moderner aussieht.

Ich habe aber ein Verständnisproblem. Ich habe aktuell 2 Branches: master und bugfix.
In bugfix mache ich alles. Neuer Code, gefixter Code, gelöschter Code.

Ich würde gerne einen eigenen Branch für neuen Code / neue Programmfeatures haben. Erstellen kann ich ihn, wie ich richtig damit umgehe ist mir aber ein absolutes Mysterium.

Angenommen ich arbeite gerade an einem neuen Programmfeature, finde einen Bug der nix mit dem Feature zu tun hat und möchte den Bug im Bugfix-Branch fixen und danach mit der aktuellen, gefixten Version im dritten Branch für das neue Programmfeature weiterarbeiten... welche Wunder muss ich vollbringen, damit das funktioniert und mir keinen Code versehentlich löscht?

Aktueller Stand: habe noch ein paar Daten offen, die nicht committed wurden. Das sind Änderungen am neuen Programmfeature und Bugfixes die nix damit zu tun haben.

Bitte wenn möglich mit nicht all zu vielen komplizierten Fachbegriffen um euch werfen

[ergeka]

Mir hat das hier geholfen meine Branches zu strukturieren

https://www.atlassian.com/git/tutori...tflow-workflow

Gruß

Ralf

[günni0]

Mein Problem fängt schon da an, dass wenn ich einen bugfix-Branch erstelle, eine Änderung mache und diese committe, dann einen feature-Branch erstelle und auschecke (also aktiviere), meine bugfix-Änderung nicht da drin ist sondern nur der erste commit von master.

Wenn ich dann zu master auschecke und bugfix und feature 1 merge, ist nichts davon im master.

[Zacherl]

Zitat von günni0:

Mein Problem fängt schon da an, dass wenn ich einen bugfix-Branch erstelle, eine Änderung mache und diese committe, dann einen feature-Branch erstelle und auschecke (also aktiviere), meine bugfix-Änderung nicht da drin ist sondern nur der erste commit von master.

Du musst erst den Branch erstellen, dann darauf switchen und dann erst deine Änderung machen und committen/pushen. Ohne dass das jetzt blöd klingen soll, wäre für dich ein Git-Tutorial sicherlich sinnvoll. Das sind eigentlich ganz elementare Operationen

[günni0]

Die Tutorials verstehe ich am allerwenigsten.
Wenn man etwas von anderen "einfach so raus" wie hier erklärt bekommt, verstehe ich das moeist besser als irgend so ein gequirrltes Tutorial

Dass man erst zu einem Branch wechseln muss, ist mir klar.

Aber wie man Branch 1 und 2 mit allen Änderungen in master bekommt ist mir ein Mysterium. Bzw Feature in bugfix mergen und dann das in master.


Ich glaube ich habs bin aber nicht sicher obs richtig ist

- bugfix auschecken, änderung machen, committen
- feature auschecken, änderung machen, commiten.

wenn ich feature in bugfix haben will, checke ich bugfix aus und klicke auf merge. dort wähle ich meinen letzten feature-commit aus und mache einen fast-forward merge. bugfix hat jetzt meine bugfixes und features.

dasselbe, um alles in master zu bekommen.


Was für mich noch gewöhnungsbedürftig ist, ist dass wenn ich jetzt 50 bugfixes in bugfix committe, dann feature auschecke, ich die bugfixes nicht in diesem feature branch habe, meine features quasi auf altem code einbaue.

[himitsu]

Hab auch ewig und paar Versuche gebraucht, bis ich bei TortoiseGIT rausfand, wie ich den Branch swtische.

Dagegen scheint mir das im SVN (TortoiseSVN) irgendwie einfacher zu sein. (auch wen SVN keine "echten" Branches kennt)

[günni0]

Ich bin die letzten 2 Stunden schon am rumprobieren gewesen und ich glaube es geht langsam in den Kopf.

Wenn ich Branch master, develope und feature habe, ich in develope etwas committe und ein feature einfügen will gehe ich so vor

- feature auschecken
- erstmal mit develope mergen damit feature auf dem Stand von bugfix ist (ist das richtig so?)
- dann das feature einbauen, committen

nun optional
- develope auschecken und mit feature mergen
- dann develope mit master mergen

[himitsu]

Zitat von günni0:

Wenn ich Branch master, develope und feature habe, ich in develope etwas committe und ein feature einfügen will gehe ich so vor

...

Also unabhängig ob SVN/GIT/Sonstwas, würde ich bei dieser Branchkonfiguration erstmal JA sagen.

[günni0]

Scheint gut zu funktionieren.
Bevor ich den Branch wechsle committe ich immer erst.

Ich denke ich lerne aber noch ein bisschen bevor ich einen dritten Branch in meinem echten Projekt anlege.

[himitsu]

Ich hab hier lokal mehrere Branches ausgecheckt
und muß demnach sowieso commiten, bevor ich es irgendwo mergen kann. (oder ...)



[Oder ...]
Meist, wenn sich rausstellt, dass man es hätte besser in einem anderen Branch hätte machen sollen.

Im SVN funktioniert es aber auch gut, dass man hier nicht comittet, einen Switch zum anderen Branch macht (Änderungen bleiben erhalten und es werden die Differenzen der Branches in das Ausgecheckte gemerget)
und anschließend im richtigen Branch eincheckt.

Oder ich erstell einen Patch/Patchdatei und patche ohne Merge etwas in einen anderen Branch rein und im ersten Branch dann löschen oder durch auschecken mit dem Rückmerge aus dem neuen Branch wieder abgleichen/eingliedern (meistens wenn es beim Switch zu viele Mergekonflikte gibt)