Wenn man mit einem expliziten Release-branch arbeitet ist es womöglich sinnvoll die Merges dort hinein mit --no-ff zu machen, dann sieht man in der Historie direkt welche Commits tatsächlich released wurden. Das ist einfacher wiederzufinden als Labels. (Leider unterstützt Jenkins das (noch) nicht).
bye
TT
Inwiefern kann und soll ein CI-Server das unterstützen? Ich dachte, dass man explizit ein Release erstellen möchte und dazu dann einfach aus dem development-Branch brancht, das Release „fertig macht“ und dann mit --no-ff in den release-Branche merget. Wo kommt da der CI-Server ins Spiel (außer mit einem Trigger auf dem release-Branch, um dann ggf. ein Deployment vorzunehmen)?
Das ist sowieso gescheiter. Wenn man - warum sei jetzt mal egal 
- einen Revert machen muss, kann es sein, dass man sich die History mit einem ff merge zerschießt.
[quote=cmrudolph]Inwiefern kann und soll ein CI-Server das unterstützen?[/quote]richtig, mein Denkfehler…
[quote=schlingel;116346]Wenn man […] einen Revert machen muss, kann es sein, dass man sich die History mit einem [no?]ff merge zerschießt.[/quote]Das Risiko besteht natürlich, aber der Prozess solte eigentlich sicher stellen, dass Reverts im zentralen Repository sehr sehr selten sind und wenn doch eins sein muss ist eben Vorsicht geboten…
Was in den lokalen Repositories passiert ist ja unerheblich…
bye
TT
Wenn du fast forwards verwendet kannst du dir die History dank Änderungen im lokalen Repo zerschießen. Das wirkt sich dann bei fast forward merges natürlich auch auf das remote Repo aus. Dann sind in der History Commits und damit Änderungen enthalten die nicht im Code enthalten sind. Unangenehme Situation… Denn dann werden auch Unterschiede in den entsprechenden Files zw. Development-Branch und master nicht mehr erkannt.
Sowas passiert natürlich nicht im Normalfall, aber bei Reverts, wenn der Ausführende wirklich wissen muss was er da tut, kann das passieren. Das kann mit --no-ff generell vermieden werden.
[quote=schlingel]Wenn du fast forwards verwendet kannst du dir die History dank Änderungen im lokalen Repo zerschießen. Das wirkt sich dann bei fast forward merges natürlich auch auf das remote Repo aus.[/quote]Mit der richtigen Konfiguration von gerrit oder GitHub könnte man das verhindern, aber wenn man nur eine Freigabe als “remote” hat ist das natürlich ein Risiko…
bye
TT