You mention that you are looking at using semantic versioning, so lets look at the semantic versioning spec at http://semver.org/:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
and a little further down:
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
So if you a releasing a true beta of your 1.0 release, you should tag it
1.0.0-beta (or similar according to the spec). If you are going to have multiple beta releases as you fix bugs, then
When you are adding features that are backwards-compatible, you should increment the MINOR number. If you make lots of internal changes that would cause breaking changes elsewhere in your application, then that is a MAJOR change. If you are making less dramatic changes (for example, you only add code and don't change behavior of existing code), then this would be a MINOR change. If you have a UI heavy application and completely change that UI, I would also say that is a MAJOR change as well (UI can be considered the API for end users).
As for how to add indicators to your git repo, I'd suggest that you first create a
1.x branch. This will allow you to easily follow everything in version 1 while allowing continued development of version 2 on master. Then you tag the beta release with a tag
-beta.1 if there will be multiple betas). Once you fix all the bugs you need to fix, tag the actual
1.0.0 release. Then tag each release as necessary.
You can take a look at some tried-and-true workflows for git like git flow and github flow for ideas of how you want to set up your ongoing workflow.
Also, if you want a little more context about semantic versioning for programs without an API, this answer goes into some depth.