Which approach is better when working with a source control software like TFS or VSS? I have experienced different approaches and I can't tell which one is better. Should we let developers decide upon it? Or should a team has a unique strategy for check-in check-out operations?
asked Jul 27, 2011 at 9:07
Add a comment
|
6 Answers
Commit early, commit often so that you don't lose data.
Branch early, branch often (for features), merge often so that you don't annoy your colleagues with lots of tiny commits to their branches when they don't want them.
Don't break the build - being the "stable" branch of your current development project from which internal releases and/or "continuous integration" builds are made.
Use a distributed VCS such as Mercurial or Git so you can enjoy the features of a local repository on your own PC. Don't forget to have back-ups of this, either by physically creating backups of your local repository, or by having a centrally managed and back-upped repository to which you can commit your local changes, in your own branch, with your own strategy.
answered Jul 27, 2011 at 9:16
It depends on your general branching strategy.
When you do feature branching or developers have private branches, then they should be encouraged to check in frequently. It does not matter, as their branch is only merged into the main branch when it is stable.
When other developers are working on the same branch, then the developer should check nothing in that breaks things for others, so larger commits are probably preferable to small and potentially dangerous ones in such scenarios.
In general, a developer should not check-in code that breaks the build and personally I'd say, that you can check-in code whenever the current set of unit-tests is statisfied.
-
Yeah, I totally agree @Falcon. Committing anything that breaks the code and prevents building, is against the principal of continuous integration. +1 Jul 27, 2011 at 9:21
-
3@Saeed: in a modern DVCS, you can have your cake and eat it by checking in frequently to your local repository, then when you're done, squash those commits and move them to the shared repository as one big commit. Jul 27, 2011 at 9:27
-
@Michael Borgwardt - Checking in frequently to your local repository is nice to have a history, but it does not protect you against data loss, which is the #1 overriding reason that you should commit frequently. Of course, if you are taking very regular backups of your local repo you might be fine, but that's not my general experience. Jul 27, 2011 at 9:38
-
3In our environment every developer's source code is backuped silently every day from the file system. The servers are also backuped daily and that's the way it should be. Source Control Repositories are not meant to be a backup device that prevents data-loss (except from recovering old versions). They can be used for it, but it's not their primary purpose. That's quite like telling a sysadmin you use a RAID mirror to prevent data-loss.– FalconJul 27, 2011 at 9:43
Check in in logical chunks. It helps to review the code when you view commit annotations.
It's easier to read: "Commit A: Added class X", "Commit B: Fixed bug Y", than to view: "Commit A: 10 bug-fixes, 5 new classes, few experimental features, and last, but not the least, source code formatting changes :evilgrin:", or "Commit A: Experimental features, checkin to avoid data loss, I'll delete it later, I promise".
-
1The "5 new classes" type of check-in comment always kind of irks me, even if there is substance in the comment text. The way I see it, check-in comments should describe what was done (fix this bug, add that menu item, whatever), from a user's point of view if possible, rather than the mechanics of how you did it. Obviously there will be exceptions, but it's the rule of thumb I try to adhere to. If your file naming scheme is somewhat sane and consistent, then looking at the list of files changed/added will tell anyone that you added a bunch of classes with little risk of misunderstandings.– userJul 27, 2011 at 11:32
Checking in early is not to prevent data loss. It's about integrating early. The longer you wait with your code, the longer someone else may be working on legacy code - something you did something with but did not share.
Check in frequently enough so you don't lose too much work when your machine breaks, and that merging your changes doesn't become too difficult when you do check in.
Check in infrequently enough that your individual commits encompass a tangible amount of progress and, of course, leave the repository in a consistent state - compileable at the very least, ideally passing all unit tests.
It's not necessary to complete a feature before checking in. While not doing so may require some "cheating" with unit tests, it's better than not checking in for a week or more, risking to lose all that work, and finally facing an impossible merge.
answered Jul 27, 2011 at 9:35
-
In addition to the data loss: we have a very dynamic team. If we don't check in minor changes, another developer cannot finish it when you are not working on it. There is no guarantee that the one who starts on a feature will be the one finishing it.– pritaeasJul 27, 2011 at 9:46
-
You can use shelving for incomplete features. And don't cheat on unit-tests, you'll forget the cheat and it will be a hard to spot bug.– CoderJul 27, 2011 at 10:44
Depends on your VCS and it's capabilities, especially merge. As eleuded to by @MadKeithV, if you use GIT or Mecurial, using local clones, commit early and often. If you use dinasours such as CVS and SVN as you main repo, then less often can be an advantage, and consider replacements.
Theres good reason to use GIT locally and deliver upto a central repo (Can be GIT/CVS/SVN or almost anything you want) at approiate times. Even better, some devs can adopt this practice and not need to force it on those that don't want it.
Devs should have some say, and the scheme needs to be fexible. We have a rule, no broken code. Incomplete code is OK, but must 'fail' in an obvious way (i.e. Unit Test not passing) and clearly be incomplete - half baked commits are dangerous.
It has to work for the Team, and each team is different.
