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


  1. Fork a repo 
  2. make changes 
  3. 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
Made with Slides.com