Git Workflow: selecting features to release from QA to PROD

I am a novice in Git and I would like to know if this idea is even possible using such a SCM.

My idea would be to have the DEV team working on features locally, then push those features to QA. At this point, when QA tested and verified the stories, the business can decide what stories are going to be installed in prod.

  • How to include a parent Spring project (using Git submodule)?
  • Jenkins “Git plugin” neither ignores commits with certain messages nor commits with from certain users
  • Solving our versioning and build problems
  • Jenkins - Dont build for specific commiter or commit message
  • Automating builds from subversion tags
  • svn deployment strategies for multiple groups of developers (not co-located) working on different components of the same project
  • So for instance DEV is working on stories A, B, C and D. Those 4 are then tested in QA but the business decide to actually install in production only B and D.

    Basically QA would have all the stories that are in PROD and possibly a few more.

    Is it even possible to do something like this using git? Do you see problems (dependencies between stories might be one of them) using this approach?

    Thanks!
    Roberto

  • Is it OK to merge another branch into mine and then merge both into master
  • Why do I get python and perl with the NDK sources?
  • Shell script self update using git
  • Git blame broken after commit with no parent
  • how to break off a sub-sequence of git commits as a separate branch + merge commit
  • How can I get git log to print the full hash and short stats of each commit on one line?
  • One Solution collect form web for “Git Workflow: selecting features to release from QA to PROD”

    Yes! I’ve written a whole article about this work-flow: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

    The key to this approach is that all features or tasks are started from the same point. This enables anyone – even non-programmers – to select the features they want in a certain environment or stage. You can dedicate a branch for each of these.

    If you want to be able to have anyone make a release with an ad-hoc mix and match of features, it is strongly recommended to share your rr-cache directory from the .git directory in your repository. This way, once a conflict is resolved, it will not need to be re-resolved when someone grabs a few features and merges them together on a new branch. This is called rerere and I explain it in the article. Further, to automate the sharing, the basic commands that you need to script are shown here: Sharing rerere cache This way you can have any non-developer also take advantage of this.

    This was not without controversy. Last year (almost a year and a half ago) there was a heated discussion about this with some programming heavy-weights. I captured the long discussion and include it so you can judge for yourself: http://dymitruk.com/old-comments-about-branch-per-feature.html

    In conclusion, this discipline will allow you to deploy at any point in time any set of features that are complete – no matter what order they were coded in.

    Git Baby is a git and github fan, let's start git clone.