Software Engineering
project-management version-control development-process
Updated Mon, 01 Aug 2022 03:27:05 GMT

When should I make the first commit to source control?


I'm never sure when a project is far enough along to first commit to source control. I tend to put off committing until the project is 'framework-complete,' and I primarily commit features from then on. (I haven't done any personal projects large enough to have a core framework too big for this.) I have a feeling this isn't best practice, though I'm not sure what could go wrong.

Let's say, for example, I have a project which consists of a single code file. It will take about 10 lines of boilerplate code, and 100 lines to get the project working with extremely basic functionality (1 or 2 features). Should I first check in:

  1. The empty file?
  2. The boilerplate code?
  3. The first features?
  4. At some other point?

Also, what are the reasons to check in at a specific point?

Solution

You should commit as soon as you have a sensible "unit" complete.

What is a unit? It depends on what you're doing; if you're creating a Visual Studio project, for example, commit the solution right after its creation, even if it doesn't have anything in it.

From there on, keep committing as often as possible, but still commit only completed "units" (e.g. classes, configurations, etc); doing so will make your life easier if something goes wrong (you can revert a small set of changes) and will reduce the likelihood of conflicts.

Comments (5)

  • +0 – I commit damn near constantly to a work branch, and I merge that branch to the mainline in units. It gives the best of both worlds in that the mainline is made of units with small sets of changes to revert, but the topic branch can let me back up just a little at a time. — Nov 22, 2012 at 17:13  
  • +0 – A commit is never too small! Don't refrain yourself from commit your changes! — Nov 22, 2012 at 19:49  
  • +1 – I'd say +1 to many small, frequent commits, depending on your work flow and how many people are interested in your repo to get their work done. Git's ability to re-write history a bit so that those 15 commits on FooSerializer can become one thing before you push helps with this. — Nov 23, 2012 at 00:28  
  • +1 – @loldop: That depends on the version control software you're using. Let's say you're using Git: you can stash what you've done, do the fix, commit it, reapply the stashed changes and restart working on them. In Subversion, you can do another checkout of the repository in another folder, fix the bug and commit to the repository there without affecting your refactoring. Or create a patch file, revert your edit, fix the bug, commit, reapply the patch. There are many ways to do it. — Nov 23, 2012 at 10:52  
  • +1 – Maybe it is a good answer to the 2nd, 3rd commit etc. But the first should be just empty. — Nov 23, 2012 at 12:44  

References