1

Git,a new Source Code Management system (SCM) after CVS and SVN

Based on the work of Christophe Demarey, Julien Vandaele

Research Centre INRIA Lille – Nord Europe

Claire Mouton Foudil Brétel

Atelir Git – October 17th 2013

2

Core Notions

3

Core notions > Get a project

checkout / clone

Repository

Developer A

Developer B

4

Developer A

Developer B

Core notions > Commit

development

Repository

5

Core notions > Commit

commitDeveloper A

Developer B

Repository

6

Core notions > Update

Repository

Developer A

Developer B

update

7

Core notions > Conflict

Repository

Developer A

Developer B

commit

8

Core notions > Conflict

Repository

Developer A

Developer B

commit

9

Core notions > Conflict

Repository

Developer A

Developer B

merge

conflict

10

Core notions > Conflict

Repository

Developer A

Developer B

diff

conflict

11

Core notions > Conflict

Repository

Developer A

Developer B

commit

12

Core notions > Branch

• Maintenance and development (maintain version N and develop version N+1)

• Work on a project sub-set (one

branch per feature)

• Experimental development

• Save commits temporarilynew

branch

mainbranch(trunk)

branch

13

Core notions > Branches merging

merge"Merge branches" :

Bring changes from a branch to another branch

newbranch

mainbranch(trunk)

14

Centralized SCM> CVS and Subversion (SVN)

15

Conclusion on centralized SCM

A central/core repository

Easy to use

Parallel work (merge) is difficult No memorizing of successive merges information The user has to remember! (to avoid conflict while merging)

Need to be on line for almost commands

Privileged users (committers)

CVS SVNDistributedSCM (Git)

past present future

16

Distributed SCM

17

Policy example: centralized

18

Policy example: distributed

19

Decentralized benefits

• Each developer can have his own repository• Off-line use (commands available offline)

– ex: Do a local commit

• Create a branch without having to ask authorization– ex: Open Source community

• Synchronisation needed between repositories• pull = get changes from a remote repository to your local repository

• push = post your changes to a remote repository

20

Exchanges between (remote) repositories

pushpull

pushpull

pull push

pull

pull

push

push

21

Decentralized SCM> Git

22

Git > History

Goal: manage efficiently big projects like "Linux"

Use of Git for the Linux kernel since june 2005

April 2005

Linus Torvalds Matt Marckall

23

Git > Local operations

commit

master

topic

Main line

Newbranch

Current line

Git user

24

Git > Conflict

commit

master

topic

conflictresolution

Git user

25

Git > Distant operations

master

origin

clone

master

pullfetch merge

cherrypick

=+

Remote machine

Local machine

26

Git > Workflow

A

B

1. clone

2. commit

3. push

> Classic working

27

Git > Workflow

A

B

1. clone

2. commit

3. push

A

B

1. pull

2. commit

> Classic working

3. push

28

Git > Bisection

badgood

? ? ?

Finds the commit introducing a bug by dichotomy

29

Git > Bisection

badgood suspectsuspect

Finds the commit introducing a bug by dichotomy

30

Git

Good visualization and branch handling, available locally:

saving of intermediary states, working on distinct features, experiments, …

Easy merge of branches, cherrypick for one single commit

All operations available locally, except push and pull

Flexible: undo / modify commits, locally before sharing

Hooks pre/post (commit, update ...)

Bisection: finds the guilty commit (the one that introduced the bug)

Efficient on big projects

Available on Linux, OS X and Windows

31

Around Git

GUIs• qgit (Qt)

• TortoiseGit via Putty (Windows)

• GitX (MacOS)

• Gitk (Windows, Linux, MacOS)

UsersLinux kernelWineX.orgAndroidKitware

Useful links• http://git-scm.com/

32

Around Git > qgit

33

Conclusion

34

Conclusion

• A decentralized SCM remains a tool• No default usage policy

• Policy to be defined– From centralized to decentralized– Pull-only vs shared-push

Anarchic Centralized Linux kernel modelBranch by functionality

orRelease train

35

Conclusion

• A decentralized SCM remains a tool• No default usage policy

• Policy to be defined– From centralized to decentralized– Pull-only vs shared-push

Centralized-style workflow Integration manager workflow