When I first started programming, working on projects both in Open Source and Corporate world – I wish someone made me aware of the Do and Don’t. For a long time, I wanted to sum them up and keep it as a checklist.
Make sure you put a commit message which makes sense. It is true that a good commit message might be difficult to come up with, but please avoid messages like “Fixed bug” or “Rendering”. Which bug did you fix? What is the bug number? What is the bug about? What rendering? What did you do with rendering? Did you fix it? Did you add rendering capability? Did you remove rendering capability?
It is a good practice to add a line of commit message title, followed by a single blank line and then an optional detailed description of the change which might not be obvious. If you made a commit which alters the working or behavior of the component, you might want to explain why you took that decision in the description section of the commit message
Check In Early, Check In Often
Jeff Atwood has an excellent post on this recommendation. My personal motto is to check-in when I am done for the day and pull in the changes when I start working for the day. I have a friend whose motto was “Every morning, you wake up and do ‘svn up’, even if you haven’t brushed your teeth”.
Keep the change-set manageable
Avoid any such scenario where your commit diff is 2000 lines unless you are nuking a component or any special scenarios. If the component you are working on enters the source tree in a single commit with 4000 lines of diff after 5 days, then STOP. THINK. Is this really the correct way? Can you do it in a better way?
If your single diff contains truck load of different features with 25 files affected, then it is a exercise in frustration for anyone who is attempting to review it. Try breaking it down such that you are able to follow “Check In Early, Check In Often”.
Learning to resolve merge conflicts
To be honest, after working on git for long time, I am still have a sigh face when I encounter a merge conflict. It isn’t always easy to fix it, but don’t forget that merge conflicts do happen and you will need to deal with it even if you collaborate on a piece of software in a very smart manner.
Get your code reviewed
No one’s code is perfect. At times, we are insecure of our coding abilities and become overly protective of our code quality. It took me time to learn that code reviews are not just about improving quality of the code, but it is a great opportunity to learn. Even if you don’t have a better programmer around, get it reviewed by your peers whom you consider at par with you.
Try reviewing code, that helps too – you learn better ways of implementing features and ideas.
If someone criticizes your code, resist from taking it personally. Usually the person criticizing your code has got nothing against you.
You don’t need to catch your team lead by the neck and demand the answer for choosing this method. Question yourself! If the lead of a project has chosen to use MVC pattern or decided to use Smarty as the templating engine, then don’t just take it for granted. Think over it. Try again! Why does this problem needs a MVC solution? Why does this needs to be implemented in Rails?
A spark of inquisitiveness goes a long way.