Our team has been using Git for a couple of years. I love it, after previously using Visual Source Safe, SVN and TFS. However, my manager has been getting increasingly agitated about it and is threatening to go back to SVN or TFS.

The problem is human nature: Developers forgetting to push up to the origin every day, then going sick or taking a holiday, and someone else having to pick up the project, and not knowing whether the latest code is in the origin, or whether it is sitting on the absent developer's machine. There is no visibility of which developer was the last to work on which file, as there is with a centralized source control system.

I really want to avoid going back to SVN of TFS. So my question is: How can a team use Git successfully in a way that takes into account human nature (forgetfulness, laziness, etc)? How can I ensure that at the end of every day the latest code has been pushed to the origin so that someone else can step in and take over the next day, if need be?

Is the answer continuous integration? I've read about workflows that include having to push to a CI branch on the origin to build the project.

  • 5
    You can't force them to push to origin, just like you can't force them to check-in the work done when using SVN. Commented Jun 28, 2014 at 15:16
  • 3
    Install automation that deletes the source tree on the developer machines every night.
    – Patrick
    Commented Jun 28, 2014 at 15:47
  • 3
    Ask the developers to stop doing that? This is a human problem. Technical means can at best gently nudge things in the right direction, and at worst have no effect aside from angering people.
    – user7043
    Commented Jun 28, 2014 at 16:40
  • 2
    Are you sure the issue is the developers? Could there be a technical aspect to your process that could be improved? For instance, if the unit and regression test suites are not adequate, daily pushups would create reluctance due to the possibility of pushing up buggy code.
    – paisanco
    Commented Jun 28, 2014 at 18:45
  • 1
    @delnan: The problem is human nature: folks tend to take shortcuts, even when told not to. If you tell people to not walk on the grass they still will, if it's quicker than going the long way round. So you need to maybe put a low wire round the grass, or similar, to make it just a little more difficult to cut across. The extra small difficulty is enough to persuade people to go around rather than cutting across. So I'm looking for a way to do that with Git, to make it easier for the developers to do the right thing than to be slack.
    – Simon Elms
    Commented Jun 29, 2014 at 3:29

3 Answers 3


The more eyes are set on any given process, the more likely it is to improve.

Use a continuos integration tool like Jenkins. They will know you are looking at a web report showing their pushes, their amount of work done and the quality of their code.

You only sweep under the rug when nobody is watching.

  • That sounds perfect. I think my manager is particularly worried about visibility, because with the centralised source control systems with SVN he had that visibility; he could see who had stuff checked out and who hadn't checked work back in in the evening. That web report sounds exactly what he needs.
    – Simon Elms
    Commented Jul 1, 2014 at 7:40

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 others code.

  • 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 Integration.

  • 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.

  • You contradict yourself: first say "coerce software developers into adopting any practice is likely to backfire." and then say "Involve them directly in the enforcement of the process". So what is it - do you have a process that says to commit regularly/daily or do you let them commit when they think its best? In my experience a lot of developers are just arrogant children who will work on any project likes its their hobby given the chance.
    – gbjbaanb
    Commented Jun 29, 2014 at 20:46
  • With respect, I disagree. You have a process that requires daily commits - you involve the developers themselves in self-policing out of their own best interest. It's more effective than management edict. No contradiction. And if the development team really is not professional, well that's a completely different issue.
    – paisanco
    Commented Jun 29, 2014 at 20:49
  • Unfortunately, not every developer is smart.
    – jmort253
    Commented Jun 29, 2014 at 21:43
  • 1
    @jmort253, I did say "as a group". There are always exceptions. And no process or management technique can fix "not smart".
    – paisanco
    Commented Jun 29, 2014 at 21:47
  • @bogeyc - There's some HR processes that can fix "not smart". I believe it's known as "termination". :D But I get what you're saying and agree 100%... you can't really treat knowledge workers like we're part of a manufacturing process.
    – jmort253
    Commented Jun 29, 2014 at 21:58

TBH if you have a centralised system when pushing to origin is necessary then you're really using git like it was SVN/TFS (ie a centralised system) in the first place. You would be better off going back to such a SCM.

However, you could migrate to Fossil which is a centralised decentralised SCM and I think is the next-gen of SCM systems.

You should also have CI implemented anyway, if you do not want to force process upon the devs, then the next best thing is to encourage them to engage with the process - and the best way to do that for many developers is to gamify it. So you have leaderboards of commits, builds, bugfixes and build failures. People often want to be at the top of such a leaderboard and will compete to get there (see SO's reputation system for an example!)

But that can only work in some cases, in most professional jobs, the boss simply has to mandate the results he wants and tells the staff to make it happen. In this case, daily commits for backup purposes and collaboration, so daily pushes have to start happening. I imagine most people simply don't do it because they forget when it comes to home time (fossil would fix this as it continually syncs changes with origin).

  • I totally agree with your I imagine most people simply don't do it because they forget when it comes to home time. I don't think people are doing it deliberately. Will check into Fossil, hadn't heard of it before. Can't help feeling that other teams seem to use git without problems and wonder how they do it.
    – Simon Elms
    Commented Jul 1, 2014 at 7:31
  • I think most people using git do so in either per-dev branches and merge when they want. I also think most places using git do not push for backups, at one place there was a definite mentality of "we don't need backups because its decentralised" (sigh).
    – gbjbaanb
    Commented Jul 2, 2014 at 22:37
  • We already tend to use per developer or per issue branches before merging into a release branch. The issue we face is one developer stepping in to take over from another on holiday or away sick: Did the absent developer remember to push their latest code up to the origin or not? It's particularly a problem when someone has been working from home and we can't access their dev machine. I'm sure other teams have run into this same issue and I wonder what they do about it.
    – Simon Elms
    Commented Jul 4, 2014 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.