Git and GitHub workflows

Git and GitHub workflows by Arthur Shvetsov CoreValue/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 (the Git way)

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

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 fetch push Local repository Stage Working directory commit checkout add pull

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

A successful Git branching model

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 develop Switched 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 Glossary ● Contributor ● Collaborator ● Public / Private repository ● Fork ● “Upstream” and “Downstream” ● Pull Request

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

Git and GitHub workflows

More Related Content

What's hot

Viewers also liked

Similar to Git and GitHub workflows

Recently uploaded

Git and GitHub workflows