c++ - Git merging/rebasing strategy for single user development -

i'm using git c++ project, , i'm sole developer. in addition maintaining code history, i'm using git because want able test new feature without modifying original code until i'm ready incorporate new feature original code. i'm using github, i'm developer.

so, here how imagine commit history might (arrows denote child commits, , arrows between branches implied):

         a1 ---> a2 ---> a3        b1 ---> b2          /                \        /        \ x1 ---> x2  ----------->  x3 ---> x4 -----> x5 ---> (...) 

in above history, a , b represent features (or changes) made. in history, worked on a first, , after finishing a started b. there may come times when i'm working on separate new features in parallel, in hypothetical example (and of time in actual development), features worked on in serial fashion.

in context, have 2 related questions. believe appropriate consolidate both questions single post.

(1) make sense create 1 "new feature" branch (e.g., testing) run alongside master used develop both a , b (and subsequent new features)? (if so, how manage process of switching between master , testing, merging or rebasing testing master, , switching testing again work on new feature?)

(2) given i'm developer make more sense merge or rebase when incorporating new feature master? i'm new git, please explain why. if answer "it depends", please explain how decide between two.

we use model @ place of employment, , think works good: http://nvie.com/posts/a-successful-git-branching-model/

so here assumptions link:

master 100 percent stable time always.

master gets merge develop when develop stable , finished.

for each feature, make branch develop.

when feature stable, merge feature branch develop.

you test features added develop ensure have added stable each other feature have done.

then merge master when 100 percent.

1: given if 'feature' , b overlap significantly, or highly dependant on each other, may wise develop both in same branch. if dont, , problems on develop test, can knock features out whilst debugging method of diagnosis. call. however, may have merge develop down feature branches should farther ahead think, because other people have committed stuff may conflict current branch, should bring else in on it.

i having feature per branch, , little work stuff develop branch. take little work since have changes develop. tradeoff, really.

as having 1 feature running parallel: can have many feature branches like. so, if bored of feature working on, make new branch develop , work on that. address merge problems in develop before goes master.

2: cant use rebase in context specified, since sharing our branches other people. id use merge if bring else mix, , voila, no trouble. this:

http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/

i hope helpful.