1 Git

1.1 Quick History

Git development began after many kernel developers were forced to give up access to the proprietary BitKeeper system (see BitKeeper for Linux and other open source projects "Zero-cost BitKeeper for Linux and other open source projects"). Permission to use BitKeeper as freeware had been withdrawn by the copyright holder Larry McVoy after he accused Andrew Tridgell of reverse engineering the BitKeeper protocols. The development of Git began on April 6, 2005, and proceeded very rapidly. The first merge of multiple branches was done on April 18, 2005, and two months later (June 16, 2005), the kernel 2.6.12 release was managed by Git.

1.2 Porcelain

1.2.1 Porcelain v. Plumbing

This book covers how to use Git with 30 or so verbs such as checkout, branch, remote, and so on. But because Git was initially a toolkit for a VCS rather than a full user-friendly VCS, it has a bunch of verbs that do low-level work and were designed to be chained together UNIX style or called from scripts. These commands are generally referred to as “plumbing” commands, and the more user-friendly commands are called “porcelain” commands.

• http://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain

1.3 Porcelain Use Cases

1.3.1 Feature Branch

1.3.2 Git Flow

1.3.3 Git Flow Branch Types

• Feature Branches
• Dev
• Release Branches
• Hotfixes
• Master

1.4 Resources

• githug
• git-it

• http://gitready.com/: best for quick reference, continuing learning
• http://think-like-a-git.net/: progressive lessons with use patterns
• http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide impressive SO community wiki
• http://www.atlassian.com/git/tutorials/comparing-workflows excellent summaries of the main git workflows
• git - the simple guide too limited for us, but same author as Frontify

2 Semver

• http://semver.org/

2.1 Basics

• MAJOR.MINOR.PATCH
• NEW_RELEASE.NEW_FEATURE.FIXED_SOMETHING

From the site:

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.

2.2 Resources

• http://sentimentalversioning.org/: Node.js, Backbone, TeX

3 Activity

3.1 githug