Git Tips

by Arthur ShvetsovCoreValue/MalkosUA

Agenda● Git common principles and design goals● Merging vs. Rebasing● How to rewrite history?● A successful Git branching model

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

o full local repositoryo offline commitso full size repository

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

Git drawbacks● Big committed files will be in every clone of

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

Git philosophy● Commit early, commit often● One commit represents one idea or one

changeo Make it easy to read patcheso Easy to revert unwanted changes later

● Your working directory, index and local repository are your scratch pads

Git architecture

Nearly Every Operation Is Local

Snapshots, Not DifferencesThe major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data.

Tracking changes (most VCS)

Storing data as changes to a base version of each file

Tracking changes (the Git way)

Storing data as snapshots of the project over time

Git Generally Only Adds Data

File status lifecycle

The Staging AreaThe staging area is a buffer between the

working directory and the project repository.

What happens when you create a commit ?

What happens when you create a new branch?$ git branch testing

How does Git know what branch you’re currently on?

What happens when you switch a branch?$ git checkout testing

Merging vs. Rebasing

Merging vs. Rebasinggit rebase and git merge - both of these commands are designed to solve the same problem - integrate changes from one branch into another branch — they just do it in very different ways.

A forked commit historyTo incorporate the new commits into your feature branch, you have two options: merging or rebasing.

Merging master into feature branch$ git checkout feature$ git merge master

Pros● Simple to use and understand● Merging is a non-destructive operation● The existing branches are not changed in any wayCons● The feature branch will have an extraneous merge

commit every time you need to incorporate changes● Visual charts of repository can have non-informative

branch lines

Git merge pros and cons

The Rebase Option$ git checkout feature$ git rebase master

Pros● Much cleaned project history● Eliminates the unnecessary merge commits required by git merge● A perfectly linear project history

Cons● Re-writing project history can be potentially catastrophic for your

collaboration workflow● Rebasing loses the context provided by a merge commit - you can’t

see when upstream changes were incorporated into the feature

Git rebase pros and cons

Git rebase golden ruleNever use git rebase on public branches. Only rebase local branches

When you rebase pushed branch, you’re abandoning existing commits and creating

new ones that are similar but different

Interactive Rebase$ git checkout feature$ git rebase -i master

Pros● Eliminating insignificant commits like this makes

your feature’s history much easier to understand. This is something that git merge simply cannot do

Interactive rebase pros, no cons :)

Force Pushing$ git push -f origin feature

Integrating an Approved Feature

Integrating an Approved Feature

Integrating an Approved Feature.“Fast forward” effect

Rebasing a temporary branch git checkout featuregit checkout -b temporary-branchgit rebase -i master

git checkout master git merge temporary-branch

Git pull --rebaseBy default, the git pull command performs a merge, but you can force it to integrate the remote branch with a rebase by passing it the --rebase option.

$ git config branch.autosetuprebase always

How to rewrite history?

Git revertReverting undoes a commit by creating a new commit. This is a safe way to undo changes, as it has no chance of re-writing the commit history.

$ git checkout hotfix$ git revert HEAD~2

Git resetGit reset as the dangerous method. When you undo with git reset, there is no way to retrieve the original copy—it is a permanent undo.

$ git checkout hotfix$ git reset HEAD~2

Reverting vs. Resetting

git checkout● checking out branches● checking out commits - makes the entire

working directory match that commit● checking out files - lets you see an old

version of that particular file, leaving the rest of your working directory untouched

“Detached HEAD” state$ git checkout HEAD~2

Multiple ways how to rewrite history?● $ git reset● $ git rebase

Git cherry-pickApplies the changes introduced by some existing commits to specific branch

$ git checkout feature-branch$ git cherry-pick <commit hash>

StashingRecords the current state of the working directory and the index, and cleans up the working directory

$ git stash

SubmodulesSubmodule allows you to keep another Git repository in a subdirectory of your repository

$ git submodule

A successful Git branching model

Decentralized but centralized

The main branches● master

o contains production ready code● develop

o an integration brancho contains the latest changeso used for nightly buildso getting a production release

when merging with master

Supporting branches● Feature branches● Release branches● Hotfix branches

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

o develop● May merge back into:

o develop● Branching name convention:

o 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:

o develop ● Must merge back into:

o develop and master ● Branch naming convention:

o 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"

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:

o master ● Must merge back into:

o develop and master ● Branch naming convention:

o hotfix-*

Creating a hotfix branch$ git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1"

$ 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).

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

Thank You!