SmartGit Verständnisproblem, 3 Branches

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



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.

[himitsu]

Nja, was dein Master ist, kann man auch sehn wie man will.
Die Release-Version oder die Develop-Version.

Du kannst alle Branches von Develop, Release oder ReleaseCandidate/TestVersion absplitten
und sogar von einem anderen Branch (mehrere Teilaufgaben/Unteraufgaben einzeln in Branches).
Die meisten nehmen wohl Release oder Develop, aber ich würde fast immer nur von Einem ausgehn, außer ein Feature braucht ein anderes noch unfertiges Feature/DevelopNeuerung.

Develop/Release/ReleaseCandidate/Master kann auch mal das Gleiche sein. (alles in Einem und eventuell einen zusätzlichen FeatureBranch)

Ob du nun alles direkt in eine "genutzte" Version/Branch mergest oder erstmal über einen ReleaseCandidate/TestVersion könnte man sich auch noch überlegt.
Stable-Branches/Versionen könnte man sich auch noch anlegen, aber wann ist schonmal alles "stabil"?

Versionen können als Tag oder als Branch angelegt sein. (kommt drauf an, ob man die später nochmal verändern will, also mehrere Versionen gleichzeitig oder ob man immer nur am Letzten Stand arbeitet)




Ach ja, DEVELOP ist praktisch auch nur ein Feature/Hotfix-Branch, halt für alles "Kleine", wo man keine Lust hat das extra abzusplitten.
Man kann DEVELOP aber bei kleineren Projekten auch Master/RC/Release ansehn und zusätzlich nur paar Feature-Branches anlegen, für größere/langwierigere Änderungen.
Oder man macht alles in nur einem einzigen Branch (DEVELOP/MASTER) und nutzt das VCS nur als Änderungslog. (vielleicht doch ab und an mal 'nen zusätlichen FeatureBranch)

[günni0]

So sieht mein Bäumchen gerade aus