Why to not commit changes to version control … before

Question

I'm novice developer, working alone. I'm using Xcode and git version control. Probably I'm not properly organised and doing things wrong, but I'm usually deciding to do commit just to make safe point before I'm spoiling everything. And at that moment I find it difficult to properly describe what I have already done, but I know exactly what I'm going to try next. So when I will do next reference point the previous is already named.

So my question is - are there some version control methodology where reference points are described by plans, not facts. Why this could be a bad idea?

Answer 1

ABC, always be committing. While you may be working on projects for yourself an no one is accountable but yourself, it is generally a good idea to commit what has been done rather than what you plan to do.

Branching is designed to save yourself from what you plan to do. Create a branch called 'addnewscreen' or whatever you plan to do. This way you can keep committing all the small changes on your new stuff without polluting your main branch. Once you are happy, merge it back in and make a new branch for what's next.

If you get stuck, the Pro-Git Book has helped me so many times I've lost count. Hopefully this will help you too. Good luck.

Answer 2

The problem with describing a commit based on what you "plan" to do is that you lose accurate accounting of what has been done. Let's say you plan on doing something, but that doesn't work. So you roll back and try something else, and that works. You commit that, but now what you "planned" to do isn't what was actually done.

At that point, you'll need to go back and edit the comments on the previous commit to describe what you actually did or risk losing a record of the change over time. Also, if you are working in a group, you pretty much need to make your comments based on what you actually did so other members of the team can see it and either check what you did or improve on it.

Unless you plan on never working on a team project, your best bet is to just bite the bullet and figure out how to keep track of what you've done since the last commit. I keep a pen and notepad by my side so I can keep track of changes. I also do frequent commits to keep from forgetting what I've done over a long period of time.