SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Modern Source and
Version Control with Git
A Distributed Version Control System (DVCS):
● created by Linus Torvalds
● maintained by Junio Hamano
● since 2005
● Most popular VCS (~30% of developers)
● started developing Git in 2006
● worked especially on git bisect
● independent consultant working for Booking.com,
GitLab and Protocol Labs
● Evolution of version control with Git
● Benefits in terms of quality and agility
Easy to create and merge branches
● Before Git, branches were something “big”, slow
and difficult to merge
● With Git, they are light and trivial
What is modern version control?
Why it changes everything?
● We want to create and merge many branches
● And we want to manage and automate the process
● This means we need:
– Feature branches
– Pull requests
– Complex workflows (like Git Flow)
Two possible reactions
● That's awesome and very smart!
● Help! I am scared, it's just too complex and
Let's keep history simple (stupid)!
We need something to linearize history!
=> git rebase is our friend
While at it, let's also merge or move or just remove
=> git rebase i is our friend
Let's go with a complex history!
● git log decorate oneline –graph
will help visualize it!
● git bisect will help find bad commits
– We can even automate it with: git bisect run
– We can skip untestable commits with:
git bisect skip
Commits in Git form a DAG
(Directed Acyclic Graph)
history direction is from left to right
new commits point to their parents
First Bad Commit
B introduces a bad behavior called "bug" or "regression"
red commits are called "bad"
blue commits are called "good"
In the end it all comes together
● When using git rebase and git bisect we realize that
they work together very well
● Let's take a look for example at code review and
Why Code Review and Testing?
● They are the best way to improve: quality and agility
● Continuous Integration and Deployment rely on
Code Review and Testing
Because you really don't want bugs in the product
you give to your customer!
Modern Code Review 1
● It's when you “polish” (rework) your commits until it is
clear that they are all good.
● This means you want:
– small commits
– good commit messages (that explain why)
Modern Code Review 2
git rebase i helps you rework commits:
● split them into smaller commits
● modify them and their commit message
● Think black box test too, not just unit tests
● Test each commit: git rebase exec <cmd>
● 1 test at least for each new feature
● 1 test at least for each bug (fixed, or not)
● 11 years ago Junio Hamano created the Git test
● Developed in shell (POSIX /bin/sh compatible)
● Extracted 5 years ago by Mathias Lafeldt into a
separate project called Sharness
● It's one of the main reasons why Git has always
been very stable
Why 1 test for each new feature?
● It shows the feature has been at least minimally
● It documents the feature
● It makes the reviewer's job easier
● It makes it easier to add more tests later
Why 1 test for each bug (fixed, or not)?
● It documents the bug
● It helps reproduce the bug
● It will make sure the bug will not reappear
● It makes the reviewer's job easier
● It's easy to do if there is already 1 test per feature
Using a git bisect based Test Workflow
● Write the test for a bug before fixing the bug
● Use git bisect run mytest to automatically find the
commit that introduced the bug
● Fix the bug (which should be easier)
● Commit the bug fix and the test together
Why a git bisect based test workflow?
● It make it easier to fix the bug
● Because it gives more accurate information
● It takes advantage of small commits
● It takes advantage of good commit messages
● People who have used it report great efficiency
Hopefully you now know what can be a modern
version control with Git, especially:
● The evolution it represents, and the logic of this
● The benefits, in terms of quality and agility, through
better code reviews and testing
Many thanks to:
● Junio Hamano, Linus Torvalds, Mathias Lafeldt
● many other great people in the Git and Linux communities
● Paris Open Source Summit organizers and attendants,
● Booking.com, GitLab and Protocol Labs, the companies I am working
● help find a first bad commit
● use a binary search algorithm for efficiency if
● manually verifying the source code changes
from only one commit is relatively easy
● the commit gives extra information: commit
message, author, ...