Git and GitHub workflows

by Arthur ShvetsovCoreValue/MalkosUA

Agenda

● Git common principles and design goals● A successful Git branching model● GitHub and how we use it

What is Git?● Git is a distributed revision control and source code

management (SCM) system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows.

● Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development.

Git design goals● Speed● Simple design● Strong support for thousands of parallel branches● Fully distributed

○ full local repository○ offline commits○ full size repository

● Able to handle large projects like Linux kernel effectively● Ensure integrity

Distributed development● Every Git working directory contains the complete

repository, history and full revision tracking capabilities● You’re not dependent on a central server and you don’t

have to be online● Git is extremely fast - much faster than SVN, CVS and

other systems● Revisions (commits) you make to your local repository

are available to you only

Distributed development● The next time you connect to the internet, push your

changes to a remote repository to share them and back them up

● The local nature of Git makes it effortless to create branches to isolate your work

● The local nature of Git makes it possible to coalesce a series of changes (local commits) into a single commit on the remote branch

Git drawbacks

● Big committed files will be in EVERY clone of repository

● No partial checkout● No lock● No support of empty directories

Tracking changes (most VCS)

Tracking changes (the Git way)

Git is a file system

“Git thinks of its data more like a set of snapshots of a mini file system.”

File status lifecycle

Understanding of workflow● Obtain a repository

○ git init or git clone● Make some changes● Stage your changes

○ git add● Commit changes to the local repository

○ git commit -m “My message”● Push changes to remote

○ git push remotename remotebranch

Remote repository

Local repository

Stage

Working directory

pushfetch

commit

addcheckout

pull

Branches

● Cheap and local (remote)● Easy to switch● Try out new ideas● Merging is way smarter

A successful Git branching model

Decentralized but centralized

The main branches

● master○ contains production ready code

● develop○ an integration branch○ contains the latest changes○ used for nightly builds○ getting a production release

when merging with master

Supporting branches

● Feature branches● Release branches● Hotfix branches

Feature branches (topic branches)● May branch off from:

○ develop● May merge back into:

○ develop● Branching name convention:

○ anything except master, develop, release-* or hotfix-*

Creating a feature branch$ git checkout -b myfeature developSwitched to a new branch “myfeature”

Incorporating a finished feature on develop$ git checkout develop Switched to branch 'develop' $ git merge myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git push origin develop

Release branches● May branch off from:

○ develop ● Must merge back into:

○ develop and master ● Branch naming convention:

○ release-*

● Used for preparation of a new production release● Allow minor bug-fixes

Creating a release branch$ git checkout -b release-1.2 develop Switched to a new branch "release-1.2" $ ./bump-version.sh 1.2 Files modified successfully, version bumped to 1.2. $ git commit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-)

Finishing a release branch$ git checkout master Switched to branch 'master' $ git merge release-1.2 Merge made by recursive. (Summary of changes) $ git tag -a 1.2

$ git checkout develop Switched to branch 'develop' $ git merge release-1.2 Merge made by recursive. (Summary of changes)

$ git branch -d release-1.2 Deleted branch release-1.2 (was ff452fe).

Hotfix branches

● May branch off from: ○ master

● Must merge back into: ○ develop and master

● Branch naming convention: ○ hotfix-*

Creating a hotfix branch$ git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1" $ ./bump-version.sh 1.2.1 Files modified successfully, version bumped to 1.2.1. $ git commit -a -m "Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-)

Working on hotfix branch$ git commit -m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-)

Finishing a hotfix branch$ git checkout master Switched to branch 'master' $ git merge hotfix-1.2.1 Merge made by recursive. (Summary of changes) $ git tag -a 1.2.1

$ git checkout develop Switched to branch 'develop' $ git merge hotfix-1.2.1 Merge made by recursive. (Summary of changes)

$ git branch -d hotfix-1.2.1 Deleted branch hotfix-1.2.1 (was abbe5d6).

GitHub

GitHub Glossary

● Contributor● Collaborator● Public / Private repository● Fork● “Upstream” and “Downstream”● Pull Request

GitHub Demo

Links and Literature

● Pro Git● A successful Git branching model● https://help.github.com/

Thank You!