Image may be NSFW.
Clik here to view.
Adi and I have been thinking about doing a session around using source control during the coderetreat. It should be a session that really motivates you to commit fast and often. It should help you to focus on taking the smallest step possible. It is only through taking the smallest step possible that you can really focus on the behavior of your system and let the design flow out of that. We really wanted to find something that helps you stay disciplined about taking really small steps.
One specific situation where this technique can prove extremely valuable is when you are discovering what a legacy system is all about. These fast commits can be a good tool to help you understand your system if you are unsure about the next step to take in your refactoring. By taking small steps and committing these, you can really start to understand the system while reducing the risk of making mistakes. You can really experiment with your system and revert easily.
First you need to setup your source control repository. It doesn’t really matter which one you use. We choose git for our example because it’s fast and easy.
Set up repository and working branch
- in the console/terminal: go to your project folder
- git init → initialize origin/master branch
- do initial setup (adding references, building project structure, …)
- commit
- git branch working_branch_name → create a branch of the master/origin
- git checkout working_branch_name → choose to work on the working branch
- git status → to check that there are no pending changes
- start working
How the session will run
- Setup a timer for 2 minutes interval when you start
- Write exactly one test
- If the timer rings and the test is red then revert and start over.
- If the test is green before timer rings then commit
- Restart timer
- Refactor
- If the timer rings and the refactoring is not complete then revert start over.
- If the refactoring is complete before the timer rings then commit
- Go to step 1
One important note: there can be no discussions in between timers, everything needs to happen within the timeboxes.
Apart from this we also need to know some basic git commands to commit changes to the branch and revert the branch to the last committed version:
How to commit
- git add . → track all the new files of the branch to version control
- git commit -a -m “commit message” → a = commit all changed files, m = message. The message cannot be missing or be empty.
- git status → to check if all changes were committed
How to revert
- git reset –hard → revert to the last committed changes on the branch
- git status → to check if all changes were reverted
How to delete the working branch when the session ends
- git checkout master → revert back to the master branch
- git branch -D working_branch_name → delete the working branch
- git clean -f -d -x → delete all the untracked files. f =force, d=directories, x=remove ignored files too
- git status → to check if all changes were reverted
What have we learned so far
After two experiments with this session we can already give you some feedback from several participants. The 2 minute rule is frustrating at first but it keeps you extremely disciplined in looking for the smallest step. It really helps you to keep yourself and your pair focused on the real problem and behavior. There is no time for gold-plating and design discussions.
A couple of the people were interested in putting this technique to use with a bigger time limit, 5 or 10 minutes for example. We had to keep the limit low enough because of the 45 minute time limit during a session. And we totally agree that when using this technique you want to aim for a bigger time limit.
If you try it out, let me know what you think about it and leave a comment here.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
