Proces z GitFlow a release branch

Zastanawiam się nad procesem Git flow.

Mamy gałęzie master, release, develop i feature.
Załóżmy, że mamy 3 feature branche (f1, f2, f3).

1. Tworzymy PR i wrzucamy na develop po kolei. Teraz jak chcemy utworzyć release branch to nie chcemy w tym wydaniu f2. Jak to rozwiązać, jeżeli release branch powstaje z developa?
2. Jeżeli nie wrzucimy f2 do develop to ma to czekać ciągle na PR? To kiedy tester ma to testować skoro po mergu do develop idzie wdrożenie na środowisko dev?

Piszę z autobusu wiec będę się streszczać
Ad.1. Feature toogle do wyłączania funkcjonalności powinien wystarczyć
Ad.2. Tymczasowe środowiska testowe z feature branchy

GitFlow nie odpowiada na te pytania:

• Co z code review? W koszernym GF nie ma miejsca na tę akcję.
• Jak wyłączyć już zaimplementowany ficzer z release'u, pomimo tego że został już wciągnięty do develop'a
• Jak zrobić merge kodu, który kisił się na feature branchu przez pół roku i już nawet nie ma go do czego mergować

Czyli jeżeli używacie GitFlow, to nie macie PR, jak macie PR, to nie używacie GitFlow

Praktycznym sposobem pozbycia się jakiejś jeszcze niedojrzałej funkcji z release'u jest tak jak ci napisał @KamilAdam, Ifik w odpowiednim miejscu, stała w innym.
Co do testowania na feature branchach uważam to za marnowanie czasu (chyba, że mowa o testach automatycznych). Kod wrzucony na feature branch nie musi być ostateczny:

• robisz feature na gałęzi
• oznajmiasz, że skończyłeś
• leci build
• ktoś zatwierdza PR, który jest w konflikcie z twoimi zmianami
• tester zaczyna testy
• musisz zmieniać kod na feature branchu
• ...

@KamilAdam: @piotrpo: W dalszym ciągu rozwiązania wydają się partyzanckie. Nie chcę gitflow by book, ale generalny koncept. Zastanawiam się czy nie lepiej tworzyć "dużego" feature brancha (np. user story) rebasowac go z develop, tworzyc feature branche(taski do tego user story) na bazie tego duzego feature i do niego mergować. Co jakiś czas rebase tego duzego brancha z develop. Po release merge tego duzego brancha do develop. Tylko teraz trzeba by tworzyc srodowisko dla testera co tez jest problematyczne

Duże feature branche są problematyczne. I nie chodzi nawet o to że trzeba rebasować, tylko o to żeby programiści się nie pobili przy kolejności merdzowania. Raz widziałem jak programistka wyżej w hierarchii wywłaszczyła podwładnego bo zmerdzował przed nią a ona miała już dość rebasowania. Kazała mu revertować jego zmiany i on musiał się rebasować. Od tej pory uważam że feature branche powinny być małe.
BTW kilka razy zdażyło mi się mieć konflikty z samym sobą gdy robiłem dwa tajski jednocześnie . To też jest nieprzyjemne :D

Nie wiem czy feature toggle jest partyzancki. Z tego co mówią, to sporo firm w ten sposób do tego podchodzi (rozdzielenie deploymentu nowego kodu od marketingowego wprowadzenie nowej funkcjonalności dla użytkowników).
Wiem, że cherry picking ficzerów nie zadziała.