Firstly, let me say that trying to coerce software developers into adopting any practice is likely to backfire. Software developers as a group are intelligent, educated people who like to be treated as professionals, and respond much better to management techniques that respect this, and treat them as valued collaborators.
So the key is to convince your developers, with logical arguments, that pushing code up daily is a good practice and will benefit them. To do this, adopt processes that facilitate the daily push-up, and get your developers to be their strongest advocates by demonstrating their advantages. Continuous Integration has been mentioned, and it is a good practice to adopt. Some of the key benefits to developers are:
Improved integration at release time. If the code base is
continuously being integrated, the risk of stressful big-bang
integration at release time, with a plethora of bugs being introduced
as multiple branches are frantically integrated, is much reduced.
Catching and fixing bugs soon after they are introduced. If a new
revision introduced a failed unit or regression test, or a new bug
not covered by these tests, it can be fixed sooner, not later when it
comes time to release, when it will be much harder to find and more stressful on the
developers. And the unit and regression tests should also be continuously refined and improved as the development proceeds.
Improved developer collaboration. As you pointed out, if everyone
commits daily, it is easier to know which developer committed the
most recent code to a specific module. What you want to do is get the
developers collaborating with each other on improving and fixing each
Daily commits make for small commits. The less code is committed, the
less likelihood it contains a large amount of bugs.
Of course for Continuous Integration to succeed, it is not just a matter of tools. It is a matter of processes there are prerequisites that need to be in place such as a good suite of unit and regression tests, and a culture of developer peer reviews of design and code. If your organization has weaknesses in any of these areas, it is to your advantage to seek training for yourself and for the team in Continuous Integration and/or processes that support it, such as Agile development.
What you want to do to succeed, is get your developers on board with Continuous Integration to the point where peer enforcement of practices like the daily commit/build/unit and regression test takes hold, and management intervention is hardly necessary. To this end as a manager you must:
Convince them of the benefits to themselves - so that they will do
the right thing out of enlightened self interest.
Involve them directly in the enforcement of the process - this means
peer reviews of design, build, and test, always and continuously.
Get them the tools and training needed to support Continuous
Lead by example. If you are involved in design and development at
all, make sure you are following the processes and being visible
about it. Point out how the processes are making your work less
stressful,and constantly encourage your developers to follow suit.