A very common question SCM newbies tend to have is when to commit your changes? I've heard a lot of ideas, ranging from one commit per day to "commit when you need someone else to debug your code". All wrong. Very wrong. So I'd like to share my point of view.
I think the best way to picture it is to imagine that you have 2 branches on one project and you want to port some changes between them. Image that at some point in time your application forked and you've been working on branch A and now there are a few different things you also want in branch B. How would you like your commits to look like? That's right, you want them to be focused on one particular change, preferably small and integral. So if I added some functionality, say, new welcome page and by the way fixed a typo on contact page, that's 2 separate commits! I may want to fix the same typo in the other branch, but not necessarily change the welcome page. When you commit changes make sure they are logically separable - that you can describe the patch in one clear sentence. Of course if you fix 3 typos on the contact page you don't need to do 3 commits, you can just go with "fixed typos on contact page". The point is some day you may need to port one particular piece of functionality to other branch, backport a bugfix to stable branch or revert some small set of changes and you'll want to access that particular change easily without affecting other parts of the code. Believe me, this simple rule will save you a lot of time in the long run.
Oct 22, 2008
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment