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