"When constructing a throwaway prototype, build only features that are poorly understood."You can think of it like this - you have started development on a big project and thought you understood all the features. Unfortunately, when you start on feature X you realize that you need more feedback from the customer and you need to provide them a prototype to use to frame the problem.
- Make a branch from Master.
- Build feature X in the new branch; we'll call it branch X.
- Share it with your customer and gather feedback.
- If the customer is happy with what you did then merge to Master and stop following this list.
More likely, you continue on along this list. - Make another branch from Master; we'll call it branch XY.
- Build feature X in branch XY using the feedback that was gathered. Pulling in code from branch X where possible.
- Make sure that the customer is happy then merge to Master.
- Finally, throwaway that branch X prototype.
By the way, until you are finished with the project, the code you have in your Master branch is really an evolutionary prototype. You want to build the features that are best understood and merge them to Master once you have customer approval. The thing to note is to never merge a feature to Master before it is well understood and approved. Anyone could make a branch from that bad code and you risk it being merged back into Master after you correct the mistake.