I understand most of the basic Git/Github concepts by now, however I still have trouble understanding the bigger picture.These are some things that I have managed to get working so far:Push commitsWork with branchesIntegrate Github with Travis CI, a continuous integration systemVia Travis CI, automatically build on every commit to master and put the release as a ZIP on Github under releases.However I have only worked on alpha/beta versions of projects so far, so I've never seen versioned releases in practice yet.Thus I want to learn more about versioning, maintaining separate versions, hotfixing the versions, etc.How would I ensure that the following things happen:Have different versions of my project, for example version 1.1.0 and 2.0.0Have the ability to push hotfixes on the versions, sort of bumping the version to 1.1.1 or 2.0.1, etc.Make a continuous integration system build that version automatically on commit and if succeeds, then publish a release for that specific version.I am doubting between the following options:Do I need to use tags for every version? If so, how can a continuous integration system build releases automatically?Should I create branches for every version? If so, would that not create a whole ton of branches (like an 1.1 and a 2.0 branch, hotfixes go onto that branch of course)How would I specify the version number? Is it okay to have a configuration file that specifies the version number, or are there smarter ways around it? In this case it would be a Java project, if that matters.
How to use github, branches and automatic releases for version management?
version control;git;github;continuous integration
You should look at git-flow. It's an excellent (and popular) branching model.Git Flow SummaryBranchingThe main trunks that stay around forever are develop and master. master holds your latest release and develop holds your latest stable development copy. Contributors create feature branches (prefixed with feature/ by convention) off of develop  :$ git checkout -b feature/my-feature developand hotfix branches (prefixed with hotfix/ by convention) off of master:# hotfix the latest version of master$ git checkout -b hotfix/hotfix-version-number master# or hotfix from a specific version$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>These branches are disposable, meaning they have a short lifespan before they are merged back to the main trunks. They are meant to encapsulate small pieces of functionality.Finishing BranchesWhen a contributor is done with a feature branch, they merge it back into develop:$ git checkout develop$ git merge --no-ff feature/my-feature$ git branch -d feature/my-featureWhen they're done with a hotfix branch, they merge it back into  both master and develop so the hotfix carries forward:$ git checkout master$ git merge --no-ff hotfix/hotfix-version-number$ git checkout develop$ git merge --no-ff hotfix/hotfix-version-number$ git branch -d hotfix/hotfix-version-numberThis is the continuous integration aspect.ReleasesWhen you're ready to start packaging up a release, you create a release branch from your stable develop branch (same as creating feature branches). You then bump the version number in a tag (described below). Using separate release branches allows you to continue developing new features on develop while you fix bugs and add finishing touches to the release branch. When you're ready to finish the release, you merge the release branch into both master and develop (just like a hotfix) so that all your changes carry forward.TaggingWhen you create a release branch or a hotfix branch, you bump the version number appropriately in a tag. With vanilla git, that looks like this:$ git tag -a <tag-name> -m <tag-description>You'll then also have to push the tags (separately) to your remote repository:$ git push --tagsIt's usually best to use semantic versioning in which your versions take the form major.minor.hotfix. Major bumps are backwards incompatible, whereas minor and hotfix bumps are not backwards incompatible (unless you're in beta, 0.x.x).MergingAs you saw above, git-flow encourages you to merge branches with the following command:$ git merge --no-ff <branch-name>The --no-ff option allows you to maintain all of your branch history without leaving a bunch of branches lying around in the current commit of the repository (so no worries, you won't have a branch for every version).You're also encouraged to pull with$ git pull --rebaseSo you don't add lots of useless merge commits.You can configure git to do both of these things by default in your .gitconfig. I'll let you look that one up though ;)Browsing versionsWhen someone is looking for a specific version of your codebase, they can checkout the tag by name:# checkout in detached HEAD to browse$ git checkout <tag-name># OR checkout and create a new local branch (as you might for a hotfix)$ git checkout -b <new-branch-name> <tag-name>Or, if someone is browsing on github, there is also a tags tab in the branches dropdown.Using the git-flow extension (recommended)My favorite way to use this model is with the git flow extension for git.(Edit: Louis has recommended the AVH fork which works better with git describe and might be more active now. Thanks Louis. )The extension automates all the messy parts (like using merge --no-ff and deleting branches after merging) so that you can get on with your life.For example, with the extension, you can create a feature branch like so:$ git flow feature start my-feature-nameand finish it like so$ git flow feature finish my-feature-nameThe commands for hotfixes and releases are similar, though they use the version number in place of a branch name, like so:# Create hotfix number 14 for this minor version.$ git flow hotfix start 2.4.14# Create the next release$ git flow release start 2.5.0Git flow then creates the version tag for you and kindly reminds you to bump the version in any configuration or manifest files (which you could do with a task manager like grunt).Hope that helps :) I'm not sure exactly how you'd integrate it all with your Travis CI setup, but I'm guessing githooks will get you there.