1. Conflicting Advice on
Alternative Git Usage Patterns
& Their Implications
SSSG, Nov. 25th, 2013
YoungSeok 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
2

3. 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%

4. Centralized Model (e.g., SVN)
Image: http://git-scm.com/book/en/Getting-Started-About-Version-Control
4

5. Distributed Model
(e.g., Git, Mercurial)
Image: http://git-scm.com/book/en/Getting-Started-About-Version-Control
5

6. My Git Experience
• Had been a Mercurial user for 3 years
• Switched to Git 2 months ago
6

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
7

8. Topic Branch Illustrated
Screenshots taken with Atlassian’s SourceTree
8

9. Topic Branch Illustrated
9

10. Topic Branch Illustrated
10

11. Topic Branch Illustrated
11

12. Topic Branch Illustrated
12

13. Topic Branch Illustrated
13

14. Topic Branch Illustrated
14

15. Topic Branch Illustrated
15

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?
16

17. Merging and Rebasing Illustrated
Plain Merge
Rebase
then Merge
17

18. 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

19. An Extremely Complex Merge Tree
Image: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/
19

20. 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

21. Example of Rebase-Then-Merge
based History
21

22. Another Situation
• Keeping the topic branch up to date
– by merging
– by rebasing
22

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
23

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
24

25. Fast-Forward Merge Illustrated
fast-forward merge
no-ff merge
Image: https://www.atlassian.com/git/tutorial/git-branches#!merge
25

26. 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

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
27

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)
28

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
29

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
30

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
31

32. Questions?
“With great power,
comes great responsibility”
32