A deeper look into

HumanTalks Grenoble 11 Février 20131Thursday, 19 June 14

About me

@sabativi

Grenoble Startup Digest Curator

Developer at Sogilis

2Thursday, 19 June 14

DISCLAIMER

http://www.jayway.com/author/philipnilsson/

3Thursday, 19 June 14

Decentralized version control like Git has a lot of

momentum right now

4Thursday, 19 June 14

STOP COMPARING SVN AND GIT

5Thursday, 19 June 14

Talk about git asA purely functional data

structure

6Thursday, 19 June 14

Preliminiaries

7Thursday, 19 June 14

A functional data structure is essentially an immutable

data structure: its values never change.

8Thursday, 19 June 14

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

+---+ +---+ +---+ +---+ | 4 +--->+ 3 +--->+ 2 +--->+ 1 | +---+ +---+ +---+ +---+ | |new list original

Immutable

+---+ +---+ +---+ +---+new list 1 -> | 4 +---+->+ 3 +--->+ 2 +--->+ 1 | +---+ / +---+ +---+ +---+ / | +---+/ originalnew list 2 -> | 9 + +---+

10Thursday, 19 June 14

Immutable

+---+ +---+updated list -> | 4 +--->+ 5 +----+ +---+ +---+ \ \ +---+ +---+ +-+-+ +---+ new list 1 -> | 4 +--->+ 3 +--->+ 2 +--->+ 1 | +---+ / +---+ +---+ +---+ / | +---+/ original new list 2 -> | 9 + +---+

11Thursday, 19 June 14

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 interferingwith 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

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

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 entirestate 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

Commiting

+---+ +---+ +---+ +---++ D +--->+ C +--->+ B +--->+ A |+---+ +---+ +---+ +---+ | |master master^

git commit

15Thursday, 19 June 14

Amending

+---+ +---+ +---+ +---+ef4d34 -> | D +--+>+ C +--->+ B +--->+ A | +---+ / +---+ +---+ +---+ / | +---+ master^master -> | E | +---+

git commit --amend

16Thursday, 19 June 14

Branching

+---+ +---+ +---+ +---+branch -> | D +--+>+ C +--->+ B +--->+ A | +---+ / +---+ +---+ +---+ / | +---+ master^master -> | E | +---+

git checkout -b

17Thursday, 19 June 14

RebasingWe want to update the commit C with a new

commit message

+---+ +---+rebased ->| D'+--->+ C'+ +---+ +---+\ \ +---+ +---+ \ +---+ +---+branch -> | D +--+>+ C +--->+ B +--->+ A | +---+ / +---+ +---+ +---+ / | +---+ master^master -> | E | +---+

git rebase18Thursday, 19 June 14

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 merge19Thursday, 19 June 14

Conclusion

20Thursday, 19 June 14

MERCI !!

21Thursday, 19 June 14