git,

github/gitlab,

gitflow

Git

git origins

The linux kernel was using a propriety VCS - Bitkeeper

Bitkeeper went pay to use

No other VCS offered the performance and distributed nature that was desired

git development

Project started 3rd April

Self-hosted 7th April

First merge of multiple branches 18th April

Kernel released using Git 16th June

What is git

Git is an open source,

distributed

version control system

designed to be

fast and branching

What is a version control system

Holds the source code for our developed products. It tracks changes made to the files, enables multiple people to work on the same set of files without too many problems

OK, but what does distributed mean?

No true central repository

All local clones are essentially repositories

All local clones have full history

Can commit work locally, even when offline

Can interact with other clones as you would a central repository

Git Good

Speed

Searching history

Diffs

Commiting

Reverting

Access different revision of files

Size

The Mozilla project's CVS repository is about 3 GB; it's about 12 GB in Subversion's fsfs format. In Git it's around 300 MB.

Distributed Nature

Branches

Git Good

Security

Better Merge History

Works easily with other VCS (git-svn, git-cvs)

SVN good

File System Structure
mkdir branches/newbranch
mkdir tag/newtag
cp trunk/* tag/newtag/
cp trunk tag/anothertag

SVN good

Subtree Access

SVN good

Version Walkthrough

Maturity

Started in 2000

distributed/decentralised

NOT a backup solution

Each peer node holds revision history

Commits are made to local repo allowing for constant commits

Frequent commits allow for easy rollbacks

Commits are pushed to the main repo when ready

decentralised/peer to peer

Branches can remain local

Inter team collaboration

Commits can be pushed or pulled between peers

branches

Branches are:

lightweight

easy to manage

things you create and destroy everyday

push-able/pull-able between peers

easy and quick to switch between

Github/Gitlab

forking

Lets you make changes and save them to Github without needing permissions on the original repo

Use original repo as a launching point for own work

Enables pull requests

Maintain your own set of features

Restrict access on central repo

forking

forking (local clone)

forking (Pull Request)

pull requests

Fork a repo
make changes
send changes to main repo

Code Control

Code Reviews

Code Review

Multiple Commits

Merge PR

wiki

Simple wiki for:

FAQs

Guides/How To

Wiki is:

Just another repo

issues

Similar to trac tickets

Milestones

Labels

Direct reference to files/line numbers

Assignees

NOT a kanban board

COLLABORATION & consolidation

easy to work with and collaborate with distant colleagues

Github vs Gitlab

Github is a hosted service

Gitlab is self-hosted

Github uses forks

Gitlab uses branches

Github costs for non-public repos

Gitlab is free for self hosted

Github is a commercial enterprise with continuous development

Gitlab offers support subs, consulting and cloud services

Github deploys updates frequently

Gitlab is intricate to install and update

Gitflow

main branches

master -> production version

develop -> production ready features

supporting branches

Feature branches

features developed in isolation

feature/umbrellas

feature/wins

HOTFIX BRANCHES

critical bug fixes

hotfix/123456

hotifx/spellingmistakes

RELEASE BRANCHES

99% release ready

final production changes

last minute hotfixes branch from here

release/2.1.0

Quick recap

Easy and independent branching

Features can remain in dev whilst still committing and don't need to be finished per release

Branches for hotifixes can merge into master for a new tag and into develop branch

Branches can be worked on by multiple people

Code review before accepting merges

3 step process for pushing to central repo

Learning curve

Integration into existing systems

How would edge servers work?

More time spent by project leads on code reviews/merging