version control - Removing features from releases in Git Flow -

version control - Removing features from releases in Git Flow -

i work on team big java code base of operations (300k+ lines of code), adopted git source command (migrated clearcase). using git flow our branching strategy. there couple of utilize cases come across have been struggling with.

we have merged of our features develop branch used in upcoming release. when close release, turns out 1 feature cannot go live (either due client not beingness ready, or other reason). what's best way create release branch, leave out specific feature (across many commits)? feature needs available included in next future release. have tried before "git revert" on commits, create release branch, "git revert" on reverted commits. pretty painful approach, particularly big features.

we have created release branch, before release goes live, it's determined feature needs removed. similar first utilize case, feature needs able go next release. because of this, doing "git revert" on commits doesn't solve completely, reverts back-merged develop branch when "git flow release finish."

as outlined in git flow model, commits made on feature branches, , never straight on develop branch. when feature finish , ready next release, merged develop. when it's time next release, release branch created off of develop. after release has been regression tested , fixed if necessary, goes production , merged master, , develop in case of bug fixes, , tagged version number. problems above come when feature thought going in next release ends needing left out.

what best methods handle these situations? in both of these scenarios, branches have been published , pulled downwards many developers, messing history can create difficulties. know these less ideal, unfortunately situations out of our control.

in git merge commit 2 things. firstly creates merge history, git knows has been merged , has not been merged. , secondly joins changes 2 divergent lines of work together.

you can trick git in both of these regards sounds need do. there 2 ways create merge history without keeping changes

git merge --strategy=ours

and

git merge git revert -m 1 merge_sha

the former creates merge commit (and merge history), leaves out changes have been merged in. later creates merge commit (and merge history) , merges in changes, removes changes while preserving first history.

in instance, if merged in , later alter mind, want utilize sec form , revert merge sha. now, maintain changes merge propagating forwards different branch want utilize first form. note in order utilize first form may have merge 1 sha @ time instead (or utilize additional feature branch this).

so imagine have branch trouble contains 6 commits (1-6), , need merge trouble master, don't want merge changes introduced in commit 4. instead of git merge trouble

git merge 3 # merges 1/2/3 git merge -s ours 4 # creates merge history 4, not merge changes 4 git merge problem # merges 5/6

git version-control merge git-flow