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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html