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
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 onlyBreaking 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
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
Commiting in Git
By Ghislain Rodrigues
