Github deploy only specific features in development branch

Question

So I am figuring out the simplest branching/deployment strategy from Github that at least has a dev and a release(master) branch. After seing this answer I think this is really close to what we need. Except the one big problem of being able to deploy only some features. Not everything.

The 2 options presented here are just not good enough. This is a common scenario and reverting everytime is plain nasty. Also, I have read that cherry picking has other issues as well specially because the cherry picked commits are actually copies (is this true?)

Now, I am thinking that if for new features that we start working on we create a branch, and we merge them to our chosen dev branch, we can merge those branches to the release branch (instead of merging from dev to the release branch, we merge from feature branch to both dev and release so we can chose what to release) so we would only have the desired changes ready for release. I can think of at least two possible issues with this:

• The feature branch has been merged to both dev and release, will this get me in trouble later?
• Will it work? since my feature branches could be based off changes made in other feature branches (they would be based off dev) when I merge the feature to dev I would have to pull first, thus adding the other features in.

So, in summary, how can i keep a dev branch, put some changes there, and later only move some stuff to another branch?.

Thanks a lot.

Answer 1

You can definitely do this. Here's what I'd recommend:

• Base all of your branches off master. This accomplishes two things:
  • Your branch is based off of production, so it's ready to go out
  • You don't have things in your branch from dev that aren't ready for release yet
• When you want to release a branch:
  • Merge branch into master
  • Deploy
  • Merge master into dev to keep it up to date. Otherwise people in dev get farther and farther away from what's in production.
• When your branch is finished, but you don't want to release, merge into dev
• When everything waiting in dev is ready to go out
  • Merge dev into master
  • Deploy

Something you'll run into is you're working on cool_feature and your coworker has branched fix_terrible_bug that you realize cool_feature needs. In that case, merge fix_terrible_bug directly into cool_feature and continue. When fix_terrible_bug is finished, it can merge into master or dev even if you're not done with cool_feature yet, and similarly you can merge cool_feature into either even if your coworker is continuing work on fix_terrible_bug. When the other branch merges, Git will do just fine (though when you're merging a lot like this, avoid rebases, they'll end up confusing things).

---

As a side note, don't worry about cherry-picks "copying" things. Every commit in Git is a bundle built from its contents, its parent commit, the current time, etc. When you cherry-pick, you're putting the same contents onto a new parent commit, so the commit hash necessarily changes and it's effectively a new commit independent of the original. That's just fine - Git is good at its job. Unless you're committing gigabytes of high def video, you're not going to notice any extra space used, and when the "original" commit joins paths with your cherry-pick, it will effectively be a no-op and eventually get garbage collected.