Commiting in Git

A new exploitable resource?

What does "commiting" mean?

To add the latest changes of a source code in a project's repository

Wikipedia

Commiting scale

What is, if any, the ideal size and content for a commit?

Commiting scale

Save and commit every time a line is changed?

Commiting scale

Do a single commit once the work is ready for QA?

Commiting scale

In the end the code is commited all the same
But extremes cases
Both unusable (crumbles of commits and Tarball commits)
Some middle-ground solutions?

Commiting scale

Commit's acceptance criterias?

Should be atomic, from the greek "atomos", "indivisible"

Just one criteria

In other words, should do one thing but well and fully without breaking the application

Commiting scale

Commit's acceptance criterias?

Issue with too small commits:

They put the state of the application in a broken state

Issue with too big commits:

They contain too much content and are hardly reviewable and debuggable

Commiting scale

How to know if a commit has the good size?

If the commit put the application in an unstable state, it might miss content.

If the commit message contains "and", it might be split into two commits.

The other way around is false though!

Commiting scale

When to commit to reach this state?

Along the way while coding, but forces the developer to always switch between the code and the VCS, not good to focus
Once the code reaches a stable state with not too many changes, but at this point the changes are not atomic anymore!

Side note: Staging area

git add --interactive

Frees the developer from having to commit along the way to let him/her... without preventing to do so still...
Increases the code's quality
accelerate code reviews

Pros

git add --interactive

Allows the developer to prepare a commit by adding manually patches of code among the local changes
Makes the developer go through his/her code (multiple times) before pushing, which acts as a pre-review

Pros

git add --interactive

~~Command line only~~ Breaking news, apparently SourceTree implemented the feature
slightly longer to do

Cons

Why the hassle?

Or how to take advantage of your commits

VCSs are used to:

Backup your code and have copies of it
Share the code within a team
ease code reviews

Why the hassle?

Or how to take advantage of your commits

But what if it can also be used to debug for example? Or to help doing code reviews?

git bisect

Binary search

Checkout commits according to binary search and asks the developer to test on the chosen commit

git bisect

Binary search

git bisect

Binary search

Important to have commits which don't break the application

git bisect

Binary search

Once the commit introducing the bug is found, the developer can then find the origin of the bug itself

git bisect

Binary search

If a commit containing a bug is huge and multi-feature (not atomic), the developer is not helped in the debug

Real life case

From one of my projects, where my commit history was not well done and I had to redo it slightly to find a bug

A quick word about code reviews

Code reviews are like reading a story
Code is like the story's setting, state of the world and the characters

Questions + resources

https://git-scm.com/docs/git-bisect

http://ghislain-rodrigues.fr/articles/git-add---interactive.html

http://seesparkbox.com/foundry/atomic_commits_with_git