New Chapter: one chapter per commit

content/books/things-i-learnt/_index.md

@@ -32,6 +32,7 @@ template = "section-contentless.html"
 		* [Good Languages Come With Integrated Documentation](languages-docs)
 	* Source Control
 		* [Always Use A Version Control System](always-vcs)
+		* [One Commit Per Change](one-change-commit)
 	* Writing code
 		* [Be Ready To Throw Your Code Away](throw-away)
 		* [Future Thinking Is Future Trashing](future-trashing)

content/books/things-i-learnt/always-vcs/index.md

@@ -30,4 +30,4 @@ change.
 And, in the long, since you'll end up with working in team and will be
 required to use a VCS, you'll be used to using one.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/languages-docs", prev_chapter_title="Good Languages Come With Integrated Documentation", next_chapter_link="/books/things-i-learnt/throw-away", next_chapter_title="Be Ready To Throw Your Code Away") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/languages-docs", prev_chapter_title="Good Languages Come With Integrated Documentation", next_chapter_link="/books/things-i-learnt/one-change-commit", next_chapter_title="One Commit Per Change") }}

content/books/things-i-learnt/one-change-commit/index.md

@@ -0,0 +1,39 @@
++++
+title = "Things I Learnt The Hard Way - One Commit Per Change"
+date = 2019-07-09
+
+[taxonomies]
+tags = ["en-au", "books", "things i learnt", "source control", "commits"]
++++
+
+When working with source control tools, keep one change per commit. Avoid
+bundling more than one change in a single commit just to "save time".
+
+<!-- more -->
+
+I've seen my fair share of commits with messages like "Fix issues #1, #2 
+and #3". This is not something you should do. One commit for fixing issue #1,
+another for #2 and yet another for #3.
+
+Just note that I said "one commit per change", not "one commit per file".
+Sometimes, to make a single change, you may need to change more than one file
+-- it may point that you have a coupling problem, but that's a different
+issue. You could, for example, make one commit which adds a new field in model
+without adding a change in the controller to load this field; after all, the
+controller won't (or, at least, shouldn't) break due the added field, and the
+model won't break (or, at least, shouldn't) break because the controller is
+not touching the field[^1].
+
+When making a commit, think this: "In case something goes wrong, can I undo
+this commit without breaking other stuff?" Commit history is stacked, so
+obviously you'd have to undo the commits on top of that one. And that's
+alright.
+
+**BONUS TIP**! If you're using `git`, you can use `git add -p` in case you
+"overchange". It will allow you to pick parts of a file, instead of adding all
+the changes in the file before committing.
+
+[^1]: Ok, it _may_ have some issues if the field can't be null, but you get
+  what I meant, right?
+
+{{ chapters(prev_chapter_link="/books/things-i-learnt/always-vcs", prev_chapter_title="Always Use A Version Control System", next_chapter_link="/books/things-i-learnt/throw-away", next_chapter_title="Be Ready To Throw Your Code Away") }}

content/books/things-i-learnt/throw-away/index.md

@@ -39,4 +39,4 @@ And not just code that solves the problem, but also the tests for that code.
 ... unless you focus mostly on [integration
 tests](/books/things-i-learnt/integration-tests).
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/always-vcs", prev_chapter_title="Always Use A Version Control System", next_chapter_link="/books/things-i-learnt/future-trashing", next_chapter_title="Future Thinking Is Future Trashing") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/always-vcs", prev_chapter_title="Always Use A Version Control System", next_chapter_link="/books/things-i-learnt/one-change-commit", next_chapter_title="One Commit Per Change") }}