In distributed source control systems, such as Git, branching is inexpensive because the branches can exist within your local repository and do not need to be shared with the central system. The overwhelming majority of experienced developers will recommend you start a new branch for every new idea that you have. Each branch can be worked on individually, and you can leave partially completed ideas in a branch if you just need to make a fix real quick to the live site.
Let's take a look at how this might play out: I've decided to build my web site using Sculpin, a static site generator. I download the starter kit and immediately create a new branch for my own "hacks" to the site. This new branch allows me to more easily make updates to the Sculpin software independently of the changes that I've made. I'm hacking away on the site and realize I'd like to add a new content type. I'm not really sure how (or if) it's a good idea, so I create a third branch to play around in. If I decide I don't want to keep the changes, I can simply return to the main branch of my work, and discard the tinkering. This is where you want to get to.
I've found newcomers to git can get frustrated and stressed out as they try to switch between branches and their work isn't committed (which prevents you from making the switch). I've also found that new developers generally hold one new idea worth of code at a time, but they aren't as likely to explore multiple new code ideas simultaneously. As a result, I recommend novices master moving backwards and forwards on a single time line, rather than moving across time lines.
On one of the early projects I worked on with a distributed version control system, I worked progressively through a few options for a client's web site. Each time I made incremental changes in a single branch, I took a snapshot of my code with both a commit, and a tag. I was able to easily show variations to the client by moving forwards or backwards in the commit history. The variations were fairly minor: colour changes, and the image used in the banner, if I remember correctly.
Branches are not complicated. With time you will absolutely come to love them! But it can be difficult to know what "deserves" a branch if you're just starting out as a team of one. In teams of more than one, it's easy: anything that's worthy of a ticket should have its own branch so that you can make the changes outlined in the ticket. As a team of one, you might not have a ticketing system. If you do, great! Use this as your basis for what gets a new branch.
Assuming you are working with a ticketing system, there will often come a time in a project where you have a group of related tickets. There will be a temptation to combine those tickets into a single feature branch. The concept of a feature branch is not unique to Git, nor are the problems associated with a feature branch.
First, the larger the unit of work in your branch, the more likely you are to get distracted and forget to keep that branch up-to-date with the main project. This can make merging your completed feature branch into the project extremely difficult. Git doesn't provide you with any suggestions on what is "too big" or "too small" of an idea for a branch. Unfortunately these decisions come with experience.
Second, if there is a problem with some part of the feature branch, it can be difficult to isolate which of the tickets are completed, and can be closed, and which are still not working and therefore must remain open. If you find yourself tempted to create a feature branch, check the tickets to make sure they are all problems whose solution can be rolled out at the same time if part of the code does not pass review.
If you don't have a ticketing system, and you aren't entirely sure how to separate your branches, you're actually in luck! You have the luxury of learning about time travel before you need to worry about parallel universes (i.e. branches). If you are working with a starter kit (such as Sculpin, Jekyll, or some other CMS), create your own content branch independent of the software you've downloaded and then work in this branch. Focus on one idea at a time. Learn to use effective tags and commit messages. If you need to reverse changes, spend the time to learn how to move along your time line of commits with
revert. This is time well invested as it will allow you to be even more effective when you work on larger projects with more complex branching patterns.