

Check In Early, Check In Often - Anon84
http://www.codinghorror.com/blog/archives/001165.html

======
delackner
I find myself working this way almost all the time. In the middle of a
refactoring or other change, I try as much as possible to get it commited by
the end of the day, in a runnable state, even if accessing the affected
unfinished area will crash. Better that than to have to walk in the next
morning and try to remember what portion of the code change is actually
finished.

In a way this is like looking at your changes as atomic operations: If a
change is so big you can't get yourself back into a runnable state by the end
of one day coding, it probably should be broken up into smaller stable steps.

~~~
huherto
For bigger changes I just work over a new branch.

------
ajross
This is great advice, but it requires significant project discipline to make
it work with large projects. Breaking builds or introducing bugs that make
your coworker's jobs harder is a cost you need to look at. Tools like git,
with per-developer "branches" might be a good choice.

But I fear that it a typical team is told to check their changes in every few
hours, this is going to cause more harm than good.

~~~
gcv
_But I fear that it a typical team is told to check their changes in every few
hours, this is going to cause more harm than good._

Let's examine the "typical team" scenario.

1\. Can't tell everyone to check in changes every few hours, because it'll
hopelessly break everyone's builds all the time.

2\. Can't tell everyone to only check in concrete working chunks, because then
people will only check in once every week. Unless people work on isolated
components, this will have a tendency to make merging progressively harder.

3\. In CVS and Subversion, can't tell people to use private branches, because
manual merge tracking means that revisions in non-trivial branches can get
lost. (This happened to me on several occasions, and the main reason why I
hate, loathe, and despise Subversion.)

4\. Can't tell people to use distributed source control, for a variety of
reasons. Politics. Fear of change. Lack of IDE integration, for the majority
of "typical teams" out there who do not understand command line tools. Lack of
interest in learning better tools ("this already works for us," and never mind
that you just spent a week before the release unravelling the mess everyone
made of the Subversion repository). Stuff like "git rebase --interactive" and
"git add --patch" is easy to use, but I personally have found it enormously
difficult to explain to other people the value of clean, well-ordered, well-
isolated revisions.

Basically, in a team where everyone proficiently, comfortably, and cleanly
wields git or hg, source control shouldn't be a problem. In any other team,
there will be problems. On my current project, I've been keeping my life sane
by using git-svn, but the rest of the team can't and won't adopt better tools,
and it struggles with the Subversion soup.

~~~
kinghajj
It scares me to think that many programmers are not comfortable with the
command-line. Sure, GUI integration is nice, but I actually prefer using Git
from the command line for most things, except for viewing history
(Gitk/Giggle) or differences (Kompare.)

------
albertcardona
The way Jeff talks, one would say he doesn't know about git-svn: commit
locally a zillion times, then just push once to the remote, shared svn server.

Which is to say: the fear of "breaking the build" should not stop you from
doing anything you want locally.

