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
git github/gitlab gitflow
By Gabriel Baker
