Conflicting Advice onAlternative Git Usage Patterns

& Their Implications

SSSG, Nov. 25th, 2013YoungSeok Yoon

(youngseok@cs.cmu.edu)

2

Git

• Distributed version control system (DVCS)

• Developed by Linus Torvalds in 2005

• Supports parallel development very well with branches

• Very popular among software developers

IBM Rational Team Concert

IBM Rational ClearCase

Mercurial

CVS

GitHub

Git

Subversion

0.9%

2.8%

3.0%

12.6%

6.8%

58.3%

0.6%

2.7%

4.6%

13.3%

12.8%

51.3%

2.2%

2.3%

2.6%

8.9%

4.4%

23.2%

46.0%

1.4%

2.2%

3.6%

4.5%

6.0%

30.3%

37.8%

What is the primary source code management system you typ-ically use? (Choose one.)

2013201220112010

PRIMARY CODE MANAGEMENT

Subversion continue to decrease to only 37.8% Git and GitHub combined represent 36.3%

Eclipse Open Source Developer Report 2013 3

4

Centralized Model (e.g., SVN)

Image: http://git-scm.com/book/en/Getting-Started-About-Version-Control

5

Distributed Model (e.g., Git, Mercurial)

Image: http://git-scm.com/book/en/Getting-Started-About-Version-Control

6

My Git Experience

• Had been a Mercurial user for 3 years

• Switched to Git 2 months ago

7

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

8

Topic Branch Illustrated

Screenshots taken with Atlassian’s SourceTree

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

Topic Branch Illustrated

16

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?

17

Merging and Rebasing Illustrated

Rebase

Plain Merge

then Merge

18

Merging

• Bringing two branches together,while preserving the commithistory 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

19

An Extremely Complex Merge Tree

Image: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/

20

Rebasing

• Rewriting the commits fromthe source branch onto thehead commit of thedestination 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

21

Example of Rebase-Then-Merge based History

22

Another Situation

• Keeping the topic branch up to date– by merging

– by rebasing

23

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

24

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

25

Fast-Forward Merge Illustrated

fast-forward merge no-ff merge

Image: https://www.atlassian.com/git/tutorial/git-branches#!merge

26

Fast-Forward Merge vs. No-FF Merge

fast-forward merge no-ff merge

• Cleaner looking SVN-like linear history

• Makes sense for relatively small, short-lived branches

• Work better with other git commands (i.e., git bisect)

• Keeps the history of what exactly happened

• The topic branch commits are clearly grouped visually

• Easy to revert the entire branch later

27

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

28

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)

29

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

30

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

31

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

32

Questions?

“With great power,comes great responsibility”