• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Conflicting Advice on Git Usage Patterns & Their Implications
 

Conflicting Advice on Git Usage Patterns & Their Implications

on

  • 229 views

 

Statistics

Views

Total Views
229
Views on SlideShare
229
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • It’s more of a “conflicting advice on alternative git usage patterns and their implications”
  • Introduce the words “push” and “pull”.
  • Say that Hg can be as powerful as Git by enabling many extensions, but they should be explicitly enabled.By default, Hg only provides safe, easy to use features.As a novice Git user, I tried to learn the Git best practices, and how things are done in git-like way, by reading articles on the Internet.During that process, I came across a lot of conflicting pieces of advice on how to use Git.Throughout this talk, I’m going to share some examples of conflicting advice of using Git, and the reasons behind their thoughts.
  • Say that it’s quite different model compared to traditional SVN model where you have very linear commit history.Why should we do that? In several words at least.
  • Say that it’s quite different model compared to traditional SVN model where you have very linear commit history.Why should we do that? In several words at least.
  • Say that it’s quite different model compared to traditional SVN model where you have very linear commit history.Why should we do that? In several words at least.
  • Say that it’s quite different model compared to traditional SVN model where you have very linear commit history.Why should we do that? In several words at least.
  • Say that it’s quite different model compared to traditional SVN model where you have very linear commit history.Why should we do that? In several words at least.
  • Say that it’s quite different model compared to traditional SVN model where you have very linear commit history.Why should we do that? In several words at least.
  • Say that it’s quite different model compared to traditional SVN model where you have very linear commit history.Why should we do that? In several words at least.
  • Say that it’s quite different model compared to traditional SVN model where you have very linear commit history.Why should we do that? In several words at least.
  • parallel vs. sequential
  • Just summarized here. (again, there is a tradeoff between these two approaches)

Conflicting Advice on Git Usage Patterns & Their Implications Conflicting Advice on Git Usage Patterns & Their Implications Presentation Transcript

  • Conflicting Advice on Alternative Git Usage Patterns & Their Implications SSSG, Nov. 25th, 2013 YoungSeok Yoon (youngseok@cs.cmu.edu)
  • Git • Distributed version control system (DVCS) • Developed by Linus Torvalds in 2005 • Supports parallel development very well with branches • Very popular among software developers 2
  • PRIMARY CODE MANAGEMENT What is the primary source code management system you typically use? (Choose one.) 37.8% 46.0% 51.3% 58.3% Subversion Git GitHub CVS Mercurial 30.3% 23.2% 12.8% 6.8% 6.0% 4.4% 4.5% 8.9% 13.3% 12.6% 3.6% 2.6% 4.6% 3.0% IBM Rational ClearCase 2.2% 2.3% 2.7% 2.8% IBM Rational Team Concert 2013 2012 2011 2010 1.4% 2.2% 0.6% 0.9% Eclipse Open Source Developer Report 2013 3  Subversion continue to decrease to only 37.8%  Git and GitHub combined represent 36.3%
  • Centralized Model (e.g., SVN) Image: http://git-scm.com/book/en/Getting-Started-About-Version-Control 4
  • Distributed Model (e.g., Git, Mercurial) Image: http://git-scm.com/book/en/Getting-Started-About-Version-Control 5
  • My Git Experience • Had been a Mercurial user for 3 years • Switched to Git 2 months ago 6
  • Typical Git Workflow • Single main development branch – Usually the ‘master’ branch • Use of topic (or feature) branches – Create a topic branch off of master – Make commits on the topic branch – Merge the topic branch into master when finished – Delete the topic branch 7
  • Topic Branch Illustrated Screenshots taken with Atlassian’s SourceTree 8
  • Topic Branch Illustrated 9
  • Topic Branch Illustrated 10
  • Topic Branch Illustrated 11
  • Topic Branch Illustrated 12
  • Topic Branch Illustrated 13
  • Topic Branch Illustrated 14
  • Topic Branch Illustrated 15
  • 1. Merge or Rebase? • The topic branch is ready to be merged • What if there were other commits made on ‘master’ while working on the topic branch? 16
  • Merging and Rebasing Illustrated Plain Merge Rebase then Merge 17
  • Merging • Bringing two branches together, while preserving the commit history of each branch • Pros – Natural and intuitive – Shows the exact context in which the feature was implemented – Better to handle merge conflicts • Cons – History can be very hard to read, when there are a lot of developers working in parallel in their own topic branches, and they are merged back to master 18
  • An Extremely Complex Merge Tree Image: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ 19
  • Rebasing • Rewriting the commits from the source branch onto the head commit of the destination branch • Pros – Much cleaner, easier to read history (i.e., no complex merge graph) • Cons – Possible to mess up the history in a team setting – Does not handle merge conflicts very well – The changes are put in a different context, which can have unexpected side effects – Losing the history of what actually happened 20
  • Example of Rebase-Then-Merge based History 21
  • Another Situation • Keeping the topic branch up to date – by merging – by rebasing 22
  • Merging vs. Rebasing: Which One to Choose? • In some situations, merging is the only option – when the topic branch is publicized – when there are merge conflicts • Otherwise, it depends on what the team or individual values the most – trade-off between traceability and cleaner history 23
  • 2. Fast-Forward Merge or Not? • Before merging a topic branch into master, suppose there are no other changes on master • Git, by default, performs a ‘fast-forward merge’ in this case 24
  • Fast-Forward Merge Illustrated fast-forward merge no-ff merge Image: https://www.atlassian.com/git/tutorial/git-branches#!merge 25
  • Fast-Forward Merge vs. No-FF Merge fast-forward merge no-ff merge • Cleaner looking SVN-like linear history • Keeps the history of what exactly happened • Makes sense for relatively small, short-lived branches • The topic branch commits are clearly grouped visually • Work better with other git commands (i.e., git bisect) • Easy to revert the entire branch later 26
  • 3. Selective Commit or Not? • Git has a staging area (or index), which is an additional layer between the git database and the working copy Image: http://azuwis.github.io/git/#/step-13 27
  • Selective Commit • Code changes in the working copy can be selectively committed using the staging area • This is useful in many situations, but can also be dangerous – the staged changes may not be tested, and may even break the build when committed (which I have already done several times) 28
  • Should Selective Commit Be Allowed? • Fortunately, there is a way of achieving both goals at the same time • ‘git stash --keep-index’ to temporarily set aside the local changes that are not added to the staging area – the changes in the staging area can now be tested directly – adds more work, but a lot safer than blindly committing 29
  • Difficulties of Mining Git Repositories • The inherent graph-based history • Branch names are not very well preserved • History rewriting commands makes it difficult to discover what exactly happened at a given time – rebase is one of the many ways of rewriting history • More detailed explanation can be found in [Bird+ MSR 09] Bird, Christian, et al. "The promises and perils of mining git.” Mining Software Repositories, 2009. MSR'09 30
  • Conclusion • Mixed feelings towards Git: – powerful enough that I have full control of how the commit history would look like – extremely difficult to learn – very easy to misuse commands and break things 31
  • Questions? “With great power, comes great responsibility” 32