Git: Getting Started

Lots of good discussion on this over at SPServices.

On the .js build process ptavares:

• Generate developer jsDocs (javadoc type of stuff)
• Generate user documentation (I used to do it with NaturalDocs, I now use Markdown)...
• Create minified version of library file(s)
• Create a distribution package (zip file with source, documentation and minified versions) 

Versioning Scheme

Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

http://semver.org/

Branches, Tags, and the Trunk -- and Stem

On a daily basis, developers in branches merge changes from the trunk into their branchMerge branch features back into trunk when you're ready to deployBug fixes are performed on the trunk then tagged and re-deployed

http://weblogs.asp.net/bsimser/archive/2008/05/06/day-to-day-with-subversion.aspx

So, development mostly occurs in the trunk (with the exception of cases where isolation e.g. of new features necessitates separation through branching), with branches corresponding to major releases (1.1, 1.2...).

The important takeaway is that for every main version of the software you are maintaining, you have a branch that contains the latest version of code for that version.

gregmac - http://stackoverflow.com/questions/16142/what-do-branch-tag-and-trunk-really-mean


Stem technique of version control: http://www.ronaldwidha.net/2009/10/04/branch-management-pattern-part-2-development-on-branch-stemming/

Never commit to master.The way of working that has worked well for us is the “never commit to master” approach (replace “master” with “default” if you use mercurial). 

http://www.stateofcode.com/2013/05/never-commit-to-master/