Am Samstag, 24. Oktober 2015, 21:45:18 schrieb Thomas Friedrichsmeier: > An addendum on this: Note that if branching is the main issue, here, > don't be shy to branch, even while rkwarddev is inside the main repo. > Just follow two very simple rules: > > 1) work branches (branches that are expected to end, sooner or later) > should be named work/xyz (for both "main" rkward code, and rkwarddev > code). > 2) release branches should be named in a way that allows to tell apart > what is being released. RKWard release branches are called > "releases/x.y.z". For rkwarddev, I'd suggest "rkwarddev/x.y.z".
that helps! do i get this right that "work/xyz" is supposed to be a branch that directly spawns from "master", not a branch "xyz" that spawns from a branch "work" (and that in turn from "master")? as far as i can tell we're currently developing in the master branch. what do think about moving toward a branching model like outlined here: http://nvie.com/posts/a-successful-git-branching-model/ https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow it would mean that "master" is always the current stable release, marked by release tags, while all development happens in a branch spawning from "master" (e.g., "work"), and single feature branches can spawn from that development branch (or kept local until it's merged into the development branch and pushed to origin). just a suggestion. viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ rkward-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/rkward-devel
