Thanks to our Sponsors!
Community Sponsor
Yearly Sponsor
Marquee Sponsor
Git Merge vs Rebase
Utah Code Camp - Spring 2016
Who Are You?
Josh Jones
Game Programmer - Wild Works
Chair - IGDA Salt Lake City/Provo Area Chapter
~8 years using git
Audience
Command Line users?
GUI users? (TortoiseGit, SmartGit, etc.)
GitHub? BitBucket? Unfuddle?
Follow Along?
These slides:
http://bit.ly/1XpxXWV (BIT DOT LY SLASH ONE X p x X W V)
Git repo:
https://github.com/vazor222/gitMergeVsRebase.git
Basic VCS Overview
Provide backups or snapshots of code as it is developed so things can easily be reverted.
Allow collaboration. Develop in parallel with branches and resolve conflicts later.
Simple workflow:
Clone/Checkout/Switch/Pull/Update/Sync/Merge - acquire code
Modify/Diff/Branch/WorkDir/Repo/Stash - edit code, view changes, store changes
Commit/Submit/Patch/ChangeSet/PR - declare your changes to the code base
Push/Commit/CopyTo/CopyUp - share code
Other amenities (blame, pull requests, line endings, ignore, etc.)
Git merge vs rebase - high level
Merge
Rebase
Preserves the most information (--no-ff)
Preserves less information
More ugly (cluttered) history
Cleaner (less cluttered) history
Easier to understand
Requires learning rebase
Less Fast-Forward merges after integration
More clean merges after integration
Pull Reviews are more clear
Can confuse Pull Reviews
Git Merge
Used to integrate two branches together.
Creates a Merge Commit unless merge is Fast Forwarded.
Local vs Remote branches.
May result in conflicts- automatically highlighted in merge commit.
Straightforward concept.
Ultimately necessary for collaboration on the same code base with branches.
Git Merge Example
Command Line
TortoiseGit
git clone
https://github.com/vazor222/gitMergeVsRebase.git
git checkout -b featureToMerge1
(make changes)
git commit -a -m "worked on my feature 1"
git checkout master
(make changes)
git commit -a -m "master my update 1"
git merge featureToMerge1 (normally pull)
git log --pretty --graph
(note the merge commit)
Right-click in workspace, clone:
https://github.com/vazor222/gitMergeVsRebase.git
Switch/Checkout... leave top option as master, check
create branch box: featureToMerge2
(make changes)
Commit to: featureToMerge2
Switch/Checkout... choose: master
(make changes)
Commit to: master (make sure master is sync'd)
Merge... choose branch: featureToMerge2
Show log
Git Rebase
Used to change where a branch is "based" - where it applies its changes and commits.
Time travel - can change history!
Generally requires you to force push after.
Upstream, Branch, and Newbase (-onto). Skips identical commits by default.
Handling merge conflicts (-abort, -continue, and -skip).
Similar commands and flags such as squash and --amend may be useful.
An immensely deep and versatile command.
Do NOT force push to
shared branches!
Git Rebase Example
git branch featureToRebase1
(on master, make changes)
git commit -a -m "master my update 2"
git checkout featureToRebase1
(make changes)
git commit -a -m "worked on my feature 2"
git rebase master (sync first, master is the upstream)
(resolve conflicts, git add, git rebase --continue)
(force push to your remote branch for PR)
git checkout master (make sure master is synced)
git merge featureToRebase1
git log --pretty --graph
(if fast-forward, note the lack of merge commit)
Create Branch... featureToRebase2 (don't switch)
(on master, make changes)
Commit to: master
Switch/Checkout... choose: featureToRebase2
(make changes)
Commit to: featureToRebase2
(you might have to click all branches in log here)
Rebase... choose upstream: master, Start Rebase
(resolve conflicts if needed until Done)
(log should show the commit from master)
Switch/Checkout... choose: master
Merge... choose branch: featureToRebase2
Show log
Git merge vs rebase - high level (again)
Merge
Rebase
Preserves the most information (--no-ff)
Preserves less information
More ugly (cluttered) history
Cleaner (less cluttered) history
Easier to understand
Requires learning rebase
Less Fast-Forward merges after integration
More clean merges after integration
Pull Reviews are more clear
Can confuse Pull Reviews
Workflows
(from general articles online- any workflow can be made with the opposite option)
Centralized (single master branch) - prefers rebase
Feature Branches (develop and master branches) - prefers merge --no-ff
Distributed/Fork Workflows - no preference/mixed
Version/Release Branches - prefers merge
Topic Branch - prefers rebase
Skullcandy Workflow - prefers merge --no-ff
Resources / Questions?
https://www.atlassian.com/git/tutorials/merging-vs-rebasing/workflow-walkthrough
http://endoflineblog.com/gitflow-considered-harmful
https://medium.com/@porteneuve/getting-solid-at-git-rebase-vs-merge-4fa1a48c53aa
https://git-scm.com/docs/git-rebase
Contact:
@vazor222
[email protected]
These slides:
http://bit.ly/1XpxXWV