1. A deeper look into
HumanTalks Grenoble 11 Février 2013
1Thursday, 19 June 14

2. About me
@sabativi
Grenoble Startup Digest Curator
Developer at Sogilis
2Thursday, 19 June 14

3. DISCLAIMER
http://www.jayway.com/author/philipnilsson/
3Thursday, 19 June 14

4. Decentralized version control
like Git has a lot of
momentum right now
4Thursday, 19 June 14

5. STOP COMPARING
SVN AND GIT
5Thursday, 19 June 14

6. Talk about git as
A purely functional data
structure
6Thursday, 19 June 14

7. Preliminiaries
7Thursday, 19 June 14

8. A functional data structure
is essentially an immutable
data structure: its values
never change.
8Thursday, 19 June 14

9. Example : A simple list
Let’s consider L: [ 3, 2, 1 ]
Let’s do operation INSERT(4) at
the front
If L is mutable then L: [ 4, 3, 2, 1 ]
9Thursday, 19 June 14

10. +---+ +---+ +---+ +---+
| 4 +--->+ 3 +--->+ 2 +--->+ 1 |
+---+ +---+ +---+ +---+
| |
new list original
Immutable
+---+ +---+ +---+ +---+
new list 1 -> | 4 +---+->+ 3 +--->+ 2 +--->+ 1 |
+---+ / +---+ +---+ +---+
/ |
+---+/ original
new list 2 -> | 9 +
+---+
10Thursday, 19 June 14

11. Immutable
+---+ +---+
updated list -> | 4 +--->+ 5 +----+
+---+ +---+
+---+ +---+ +-+-+ +---+
new list 1 -> | 4 +--->+ 3 +--->+ 2 +--->+ 1 |
+---+ / +---+ +---+ +---+
/ |
+---+/ original
new list 2 -> | 9 +
+---+
11Thursday, 19 June 14

12. GIT VS PURELY
FUNCTIONAL DATA
To update our code base
with new versions,
keeping old versions
available.
Collaborating on a single
code base without
updates interfering
with each other in an
unpredicable way.
Update data structure
while keeping the old
value of that data
available.
Updating a structure in
one place without
interfering with someone
elses updates of that
structure.
12Thursday, 19 June 14

13. Git basically is a purely
functional data structure,
with a command line
client that allows you to
perform operations on it.
13Thursday, 19 June 14

14. Let’s say we have a repository containing
commits A, B and C in that order, in the master
branch. We’ve told Git to store the entire
state of our working directory three times
during development.
We can represent this state of development as
the history [C,B,A]
+---+ +---+ +---+
+ C +--->+ B +--->+ A |
+---+ +---+ +---+
|
master
14Thursday, 19 June 14

15. Commiting
+---+ +---+ +---+ +---+
+ D +--->+ C +--->+ B +--->+ A |
+---+ +---+ +---+ +---+
| |
master master^
git commit
15Thursday, 19 June 14

16. Amending
+---+ +---+ +---+ +---+
ef4d34 -> | D +--+>+ C +--->+ B +--->+ A |
+---+ / +---+ +---+ +---+
/ |
+---+ master^
master -> | E |
+---+
git commit --amend
16Thursday, 19 June 14

17. Branching
+---+ +---+ +---+ +---+
branch -> | D +--+>+ C +--->+ B +--->+ A |
+---+ / +---+ +---+ +---+
/ |
+---+ master^
master -> | E |
+---+
git checkout -b
17Thursday, 19 June 14

18. Rebasing
We want to update the commit C with a new
commit message
+---+ +---+
rebased ->| D'+--->+ C'+
+---+ +---+
+---+ +---+ +---+ +---+
branch -> | D +--+>+ C +--->+ B +--->+ A |
+---+ / +---+ +---+ +---+
/ |
+---+ master^
master -> | E |
+---+
git rebase
18Thursday, 19 June 14

19. Merging
Merging introduces a bit more complexity to our model.
Instead of our history being a tree, it is now an acyclic
graph.
+---+
--+ X |
+---+/ +---+
| M |
+---+ +---+
--+ Y |
+---+
git merge
19Thursday, 19 June 14

20. Conclusion
20Thursday, 19 June 14

21. MERCI !!
21Thursday, 19 June 14