Git It Together Discussing Source Control · GitFlow Introduced by Vincent Driessen in his post...

Preview:

Citation preview

Git It TogetherDiscussing Source Control

Nick Harris

Kyle Richter

Janene Pappas

Ben Lachman

Daniel Pfeiffer

Brett Jones

Overview

Quick History of Source Control

A Look at Popular Solutions Used Today

Panelist

Open Discussion

The first thing to know about source control…

USE IT!Seriously. You should.

Why use Source Control?

Backup of your hard work

History of the code base

Collaborating on code

Maintaining multiple versions of an app

Early Source Control System

Early Source Control System

Source Code Control System (SCCS) - 1972

Revision Control System (RCS) - 1982

Concurrent Version System (CVS) - 1990

BitKeeper - 2000

Modern Source Control Systems

Subversion (SVN) - 2000

Mercurial (Hg) - 2005

Git - 2005

Subversion (SVN)

Centralized Source Control System

Notable Companies are Apple and Omni Group

Use to be the default Source Control option in Xcode

Created by CollabNet to Supercede CVS

Became a Top-Level Apache Project in 2010

Mercurial (hg)

Free under the GNU GPL v2+ license

Created by Matt Mackall in response to BitKeeper price change

Used by Adium, Growl and Python

Distributed Source Control written mostly in Python

Git

Official Source Control of the Linux Kernel

Also created as a response to pricing change of BitKeeper

Used by virtually everyone

Distributed Source Control written mostly in C and Perl

Created by Linus Torvalds

Free under the GNU GPL v2+ license

Common Features

Branching Strategies

Central

Feature

GitFlow

Central

One branch typically called Master or Trunk on Subversion

Changes are made then committed back to Master/Trunk branch

Feature

Features are developed on their own dedicated branch

Limits merges into the master/trunk branch until a feature is complete

Supports parallel feature implementation work

GitFlowIntroduced by Vincent Driessen in his post

“A successful Git branching model”

Two long running branches called Master and Develop

Master is production ready and/or production deployed code

Develop is code ready for the next release

GitFlow

Feature branches for separate feature development

Features can be long running branches or short lived small user stories

Release branches when in code freeze prior to an app release

Release branches are merged back to master and tagged

Hot fix branches off of tagged master commit then merged back in master when released

GitFlow

GitFlow

Real World Use Cases

Brent Simmons (@brentsimmons) write up via email

One single Subversion repository for everything(multiple products, shared frameworks, designs, docs, websites)

Repository is enormous. Moving from a central to distributed setup is unreasonable

Branches are created close to release to isolate shared framework code

My Experience

Spent 7 years building desktop and services using Delphi and .Net

Used Visual Source Safe, SourceGear Vault and Team Foundation Server

Moved to Mercurial and BitBucket for Social Sites and Glassboard

Use Git and GitHub Today

GitFlow With Feature TeamsTwo Permanent Branches - Master and Develop

Long Running Major Feature Branches

Release Branches During Code Freeze

Jira Stories in Single Feature Branch

Bugs In Single Bug fix Branch

Pull Request for Code Review Prior to Merge

Constant Merging Between Branches

Panelist

Copyright © 2015 Float Mobile Learning. All rights reserved.www.floatlearning.com

NBA development

• Large and small releases, 1-2 per month• 3-6 developers working concurrently• github/pull requests• jira• jenkins CI

git flow

the workflow

• master - the historical branch• develop - work towards the next release contributed here

• feature branches - NBA-1234_Short_Description• branch from develop, merge into develop

• fix branches - EFIX_NBA-1234_Short_Description• branch from master, merge into master and develop

• release branches• branch from develop, merge into master and develop

why git flow

• Parallel development• Simple to understand• Adaptable• Fits the pull request workflow• CI integration• Structured, Separation of concerns

links

• http://nvie.com/posts/a-successful-git-branching-model/• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/• https://github.com/nvie/gitflow

Panelist

Open Discussion

Thanks!

Recommended