git and github workflows
DESCRIPTION
Explanation of Git and GiHub workflows.TRANSCRIPT
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!