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:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. 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 1.0.0-beta.1, 1.0.0-beta.2, etc.

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 1.0.0-beta (or -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.

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:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. 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 1.0.0-beta.1, 1.0.0-beta.2, etc.

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 1.0.0-beta (or -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.