2

We are developing a feature in feature/x. We need to merge this feature into master every now and then and also merge master back to feature/x to stay in sync. The feature/x branch also exists as a remote branch, so rebasing is not a very good option here.

We want to disable/hide the actual feature in master until some point in future. In fact, I'd like to be able to create a commit K in master such that it disables the feature being developed by hiding it in the UI but preserves the underlying mechanisms.

I'd also want this to work so that when I merge from master to feature/x, I'll get all commits except K. Also, when I merge from feature/x to master, the commit K should still apply in master, keeping the feature hidden.

I've tried

git co master
git commit -am "disable feature x for now"
    => created commit 12345678
git co feature/x
git merge -s ours 12345678

This works except the feature gets re-enabled in master when I do

git co master
git merge feature/x

So it seems that merging with -s ours from master to feature/x doesn't result to merge working both ways. So each time I merge from feature/x to master I'll have to disable the feature again and then this disabling commit will flow back to feature/x and so on. Is there a better way?

raimohanska
  • 3,265
  • 17
  • 28

2 Answers2

1

The problem is that what you are really trying to do is a rebase. You could spin fresh branches for each rebase you do, but depending on how frequently you do this it may be impractical.

It's an extra step, but you could set up a (non remoted) branch feature/disable_x that contains just the patch to disable x. Then when you merge feature/x in, rebase and merge disable_x as well.

Oliver Matthews
  • 7,497
  • 3
  • 33
  • 36
  • This does help even though it doesn't do exactly what I'd like to do, i.e. merge both ways without having to do an extra disabling step more than one ever. – raimohanska Nov 28 '13 at 11:07
1

Consider using feature flags (or feature toggles).

This allows code to be merged on master but only being available after some flag is toggled (the feature is enabled).

The advantages are numerous:

  • easier code management (the code is live)
  • easy fallback if something goes wrong: just switch the flag again
  • easy gradual go-live: only enable a feature for a few users

Disadvantage: you will have to add some code to manage these flags. But depending on your language/coding platform, libraries will already be available supporting this.

nathanvda
  • 49,707
  • 13
  • 117
  • 139
  • Thanks. This is actually the solution we ended up using. It is indeed more flexible than a version-control based approach. – raimohanska Nov 28 '13 at 11:05