To keep track of the original repo, you need to add another remote named upstream:
git remote add upstream https://github.com/octocat/Spoon-Knife.git # Assigns the original repo to a remote called “upstream”
Pull in upstream changes
If the original repo you forked your project from gets updated, you can add those updates to your fork by running the following code:
git fetch upstream # Fetches any new changes from the original repo
git merge upstream/master # Merges any changes fetched into your working files
I like this:
major: Really a marketing decision. Are you ready to call the version 1.0? Does the company consider this a major version for which customers might have to pay more, or is it an update of the current major version which may be free? Less of an R&D decision and more a product decision.
minor: Starts from 0 whenever major is incremented. +1 for every version that goes public.
release: Every time you hit a development milestone and release the product, even internally (e.g. to QA), increment this. This is especially important for communication between teams in the organization. Needless to say, never release the same ‘release’ twice (even internally). Reset to 0 upon minor++ or major++.
build: Can be a SVN/Git version, I find that works best.
For larger projects with many components Semantic Versioning makes sense, though it less end-user friendly.