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:
- The empty file?
- The boilerplate code?
- The first features?
- At some other point?
Also, what are the reasons to check in at a specific point?
Related: "Git for personal projects: Overkill?"
Go by units
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.
Ghost towns
John MacIntyre Answers (1 vote):
As far as I'm concerned, your source control repo is part of the basic project setup, so I commit right after I generate my empty project.
Related: "When is a version control commit too large?"
Leave traces on multi-person projects
My rule of thumb is to check in once my solution file (or other build script piece) is done, even if it contains a few files that are empty. It's good practice for when more than one person is working on the project. That file tends to have the worst merge issues initially as people are adding things to the project so needs committed early and often.
Even if you're the only one working on the project and it's only got one file, I find it easier to follow the same workflow and save the thinking for the problem at hand.
README development
Tapan Karecha Answers (63 votes):
The first commit can be a README file with as little as one line summary of the project, or enough information about the project's first milestone. The broad topics can also include:
- Introduction
- Project description
- Project structure
- Coding conventions
- Instructions on how to:
- build
- test
- deploy
- Known issues and workarounds
- todo list
- Terms of use
The practice of updating the README before making changes to a project is also referred to as Readme Driven Development and it allows you to think through the changes before investing time in making those changes.
Anybody who wants to contribute to or use this software will then start with the README.
Find the original post here. See more Q&A like this at Programmers, a site for conceptual programming questions at Stack Exchange. And of course, feel free to ask your own.
reader comments
33