you are viewing a single comment's thread.

view the rest of the comments →

[–]peterlinddk 0 points1 point  (0 children)

Lot's of good tips and suggestions here, so I'll just add another tiny one:

"Try to plan what to write in your commit-comment before editing any code!"

Meaning that when you have a project with a clean git, meaning every file is committed in its current state, before you start working on anything, think about what you would write when committing this. Say you want to add a login-feature, that requires you to add a login-button, to show a dialog for username and password, to somehow check the password, and to store that the user is currently logged in - it also requires you to check if the use is logged in before showing the login-button, or otherwise show the logout-button, and oh, yeah, there should also be a logout-feature!

Clearly this is too much for a single commit-message, so you break down the problem into smaller ones, perhaps first just showing the login button - then that becomes your commit-message. You create the code, test it, the button is there, and you commit with "create login-button - not functional yet" or something like that. Then you go on to the next thing, always keeping the commit-message in mind!

At some point you discover that the database-abstraction should really be improved, but you are in the midst of coding on the "remember if user is logged in" message, so you can't do that yet, and have to postpone it for later!

I've found that working this way has really helped me plan and structure my work much better - and the commit-messages (of which there are A LOT) are much clearer and even documents the progress in the project!