SmartGit Verständnisproblem, 3 Branches

[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)

[günni0]

Eine Frage bleibt noch offen.

Der Fall ist man hat Branch master (Code Zustand "1"), develop (Code Zustand "2") und feature (Code Zustand "2").

Der aktive Branch ist develop. Ich behebe jetzt einen Fehler in develop und committe es. Der Zustand des Codes in develop ist nun 3.
Die 3 soll nur symbolisch darstellen, wie weit fortgeschritten der Code ist.

Jetzt möchte ich ein Feature einbauen und checke feature aus. Der Zustand von Feature ist aber noch der, bevor ich den Fehler in develop behoben habe - also Zustand 2.

Merge ich jetzt feature mit develop, sodass feature den Zustand von develop hat (also 3) und das rum-ge-merge muss immer nach einem Wechsel von develop zu feature und umgekehrt gemacht werden, oder arbeitet man in feature erst mit der alten Version des Codes weiter und merged erst ganz zum Schluss?
Beim mergen ganz zum Schluss würde man halt immer nur mit altem Code arbeiten, was mir irgendwie komisch vorkommt.

[Aviator]

Das kommt, finde ich, immer ganz auf das Feature an, das gefixt werden muss bzw. an dem weitergearbeitet werden soll. Ich bin zwar auch ein Freund davon immer mit der aktuellsten Version zu arbeiten, aber das entscheide ich immer von Fall zu Fall.

Was mir beim Erstellen meiner Branches weitergeholfen hast, war das Bild in diesem Tutorial. Schau dir das Bild ruhig mal ein paar Minuten an. Das ist dann doch ziemlich selbsterklärend und da sind alle deine Fälle die du angesprochen hast mit Pfeilen schön dargestellt.

GIT Branching.png

Das System musst du dann eben eventuell etwas auf dich anpassen bevor du das richtig benutzen kannst. Ich persönlich arbeite seit 2015 mit GIT und lerne auch immer wieder etwas dazu. Vor allem, wenn man dann nicht nur lokal mit einem GIT Repo arbeitet, sondern auch noch ein Issue Tracker wie GitHub oder GitLab (welches ich verwende und im Netzwerk hoste) nutzt. Dann ist das wieder etwas anders, da man dann mit Merge Requests bzw. Pull Requests arbeitet.

[günni0]

Mit dem mergen funktioniert es nun auch besser als vorher.
Das Bild da oben ähnelt dem Chaos der in der deutschen Politik herrscht *räusper*

Ich bin froh, dass ich es mit 3 branches hinbekomme.
Eben habe ich auch in 2 verschiedenen gearbeitet und dann die aktuellste Version des Codes von develop in feature gemerged.
Bin stolz wie Bolle es fast kapiert zu haben.