Re: stable as subset of develop

W dniu 27.08.2016 o 04:29, Brett Porter pisze:

In a small group, develop is the branch where all fixes/additions/... from topic
branches are merged rather dynamically. Thorough testing of commits
may lag behind, but when we think one is a pretty good commit we want
to identify it as (at least relatively) the latest stable. We could
tag it, but we would like these stable commits to be a branch in the
sense that each commit points back to a previous commit.

Merging from a development branch commit to stable isn't quite what
we want. It seems more like:

  checkout the new good development commit
  change HEAD to the head of the stable branch
  git add --all
  git commit
  (maybe tag the new commit with the hash of the chosen development commit)

If you are really using topic branches, a better workflow would be
to make use of them.  That is, do the development of new features
on topic branches, test them in relative isolation, and when deemed
ready merge them into development branch, for more testing (including
integration testing).

Then, those topic branches that are considered stable are merged
into stable branch ("trunk").  You can think of it as picking
features to have in stable.

Take a look at Junio's blog posts about this topic.

Will that work (one thing beyond my current understanding is if there
are index complications)? Other ideas?

That looks a bit like reimplementation of cherry-picking.

Also, I think you would loose the ability to run git-bisect to find
bad commits.
 

This could help with applying successively more intense testing over
time and chase down where problems arose.

Reiterationg: if you are using topic branches, use topic-branch workflow.

-- 
Jakub Narębski

author of "Mastering Git"
https://www.packtpub.com/application-development/mastering-git