During work, i only make commit and push my work to our shared repository at Github, when i consider that I have done my task up to necessary changes which I may realize later. So that means that I don't commit and push my work on a daily basis, but often once in several days.

Generally, is daily commit and push necessary for managers and supervisors to check my progress and productivity? Is it especially true in Agile?

If i commit and push at the end of each day, chances are my work is paused at the middle of something. What shall I write in the comment of the commit? I feel that I can write something in the comment only when I have completed some task up to some future changes realized later.



I am working on my own feature branch, so i only push to my feature branch at Github. When my work is ready on my feature branch to be merged into the master branch, i will create a pull request to the person who has the ability to merge.

  • 9
    So what happens if you spend a week on a particularly difficult bit of code and your hard drive crashes right before you commit? Commented Apr 6, 2017 at 16:26
  • 2
    Possible duplicate of When to commit code?
    – gnat
    Commented Apr 6, 2017 at 16:26
  • 2
    @gnat: This is not a duplicate, due to the "management" factor. It does change things. Commented Apr 6, 2017 at 16:41
  • 1
    @DanPichelman: I think I'd open my backup app, pull the most recent stuff from my provider and lose maybe the last 20 minutes' worth of work. 'Cause we all back our stuff up, right? ;-)
    – Blrfl
    Commented Apr 6, 2017 at 18:12
  • 2
    @GregBurghardt when it comes to code version control any "management" factor becomes totally negligible compared to convenience of developers. Using VCS for anything other than making developers most productive (as discussed in duplicate question) is a serious abuse. If management finds that natural flow of commits doesn't suffice to make them feel good they need to find other ways to communicate progress (as one of most popular examples I've seen daily updates to issue tracker do the job, and I've seen other ways that don't misuse development tool for managerial communication)
    – gnat
    Commented Apr 6, 2017 at 20:09

6 Answers 6


It should not be necessary for you to commit daily just to assure your managers that you are working. If management can't tell how you're doing without looking at your commit history, then I would argue they are not very good at management. Maybe one step above counting LOC to see how good a worker you are. If management engages in closely monitoring your commit history, that feels like a really annoying (and time-wasting) form of micromanagement.

Management should be more concerned with whether or not your features are completed on time, and if they work as per the specs.

What you didn't actually state in your question: Does your manager(s) actually complain that you are not making enough commits?

All that aside, I commit several times per day. When my code is in a good state that I want to preserve, I commit and push, and on a good day, this happens several times per day. But the details of this are a completely different discussion than the one you asked about.


Generally, is daily commit and push necessary for managers and supervisors to check my progress and productivity? Is it especially true in Agile?

Well, it's good practice to commit code at least once a day, to ensure you're not keeping hours of valuable work hostage on your workstation!

But, for "true agile?" No.

For managers to "check your progress?" Not really. A better check of progress and work ethic is velocity over time and 1-to-1 dialogues.

That said, we don't know your team dynamic. And, one of the most basic principles of "Agile" development is, "do what works for you." Your team needs to discuss these policies internally (with your manager) to determine why or if this procedure is helpful.

And from my own experience as both a developer and a manager, regular checkins aren't necessarily a product of an overbearing manager. They can also be a sign of a manager (or team) who's actually interested in your work or wellbeing. Or a manager who's interested in not losing days of your work if you get his by a bus ...

I should also note, from my experience on both ends, that when someone — myself included — isn't making regular pushes, they've usually "checked out." That is, they're not actually working. And more importantly, they've stopped caring.

So, as long as you're actually doing work, and as long as writing code is a daily responsibility of yours, you shouldn't be afraid to push code every day. If you find that difficult, you might be in the wrong job! And, that's something both your manager and you should want to see the early signs of!

And I mean that seriously. When I'm in development mode on a project, if I get to the end of the day and can't push my code, it's never because my code doesn't compile or I'm embarrassed. It's because I didn't work. ... So, I either walk up to someone at the office and make a commitment to them1, which a great motivator, or I start looking for another job. (Or both.)

1. That is, I walk up to a stakeholder or my manager and say, "Hey, I'd like you to review my work at the end of the day tomorrow." And to be perfectly honest, after a few days of this routine, I usually stop looking for another job, because I'm engaged again. I care again, because I'm no longer working for a vague corporate entity. I'm serving my coworkers.

  • 1
    "But, for "true agile?" No." How do you do "true agile" if you're not doing continuous integration? Commented Apr 7, 2017 at 14:58
  • "Well, it's good practice to commit code at least once a day, to ensure you're not keeping hours of valuable work hostage on your workstation!": The git (or mercurial or whatever) repository is not a backup facility! To make backups you can use an external disk or a network drive. But please, do not fill the change history with microcommits that in six months from now you won't be able to understand. The change history in the repository should only contain meaningful changes that introduce new features of fix bugs. They are not the daily log of each programmer's activities.
    – Giorgio
    Commented Apr 7, 2017 at 15:13
  • @Giorgio If you wrote code today, putting it someplace your team can see it today isn't "backup" ... And, if you're branching and merging properly, your "micro-commits" really won't bother anyone.
    – svidgen
    Commented Apr 7, 2017 at 15:41
  • 1
    @RobCrawford I sincerely hope you're joking. ... While I'd advocate very strongly for CI, it is by no means necessary in Agile development.
    – svidgen
    Commented Apr 7, 2017 at 15:42
  • 1
    @RobCrawford Unmerged code is risk regardless of whether you're "agile."
    – svidgen
    Commented Apr 14, 2017 at 13:37

Generally, is daily commit and push necessary for managers and supervisors to check my progress and productivity? Is it especially true in Agile?

No. Absolutely not (see When to commit code? and Is committing/checking in code everyday a good practice?). This is what your daily Scrum/stand up is for. They should also be looking at daily burndown charts. Look at past sprints to gauge the velocity of the team. If management needs more proof that you are working, then they need to either:

  1. Come to or dial in to your daily Scrum or stand up

  2. Actually come down to where the developers are and walk around

  3. Ban telecommuting (as unpopular as that would be)

  4. All of the above

I think the real question is: why do managers need a constant stream of code changes in order to believe developers are doing something?

But that's a separate question: How can I demonstrate my productivity to management?

  • 2
    Uhh ... wait. What? ... Why is this getting upvoted like crazy!? Progress checks are not what stand-up is for. Stand-up is a catalyst for communication and identifying and removing blockers! ... Secondly, how can you pretend to know this guy's team dynamic? ... Maybe, on his team, it is necessary to perform daily pushes, because the team is struggling to stay focused!
    – svidgen
    Commented Apr 6, 2017 at 16:59
  • 1
    @svidgen: I had a coworker tell me once to "love the code, not the application." The subject matter of the application might not be the most exciting thing in the world, but that doesn't mean engineers shouldn't find joy in writing the code. It's all in what you find enjoyable. Now let's just hope the problems brought up by the litany of expense reports and basic CRUD applications we must deal with are interesting problems... Commented Apr 6, 2017 at 17:09
  • 3
    I up-voted this not because I think the daily stand-up's purpose is to provide a progress update to the manager, but because the conversations in the stand-up should be enough to satisfy the manager's needs. If meaningful daily conversations are taking place, then there should be no need for a daily "commit and push". If there are other reasons for requiring daily commits, then so be it. But not for progress checks.
    – Eric King
    Commented Apr 6, 2017 at 17:42
  • 1
    @EricKing I dunno. I don't know that I agree. Having been on both sides, it can easy to deceive oneself into thinking a task is way more complicated than it really is ... and to say, day after day, "Oh, I'm still working on X. It's a real thinker." ... Well, OK. If it's really a thinker, you should either be committing experimental code or producing diagrams or having conversations with people, any of which a manager can use as a sign of life that a standup can't really provide. I've seen way too many folks overstate complexity for a week ... and then commit a few simple lines on Friday.
    – svidgen
    Commented Apr 6, 2017 at 17:50
  • 2
    This is an incorrect statement: "This is what your daily Scrum/stand up is for". The daily scrum is for team members to sync up. It is not in the slightest to be a tool to keep management in the loop. Management can look at burndown charts and the story board and speak with the scrum master and team members, but the daily scrum should be for developers only. Commented Apr 7, 2017 at 3:30

One thing I would note is that if your manager is telling you that daily commits are necessary, then they are necessary regardless of how you personally feel about it.

Another circumstance not noted in the other answers, which is particularly relevant these days, is when you are working remotely. If you are working remotely, your manager can't swing by your desk to check on your status and make sure you are actually working. They might be able to ping you on Slack and you might still have weekly meetings on Skype/Zoom/whatever, but that doesn't give the full picture. Are you actually at your desk for all of the hours you say you're working? Are you actually writing code, or are you browsing the internet or playing video games?

Unfinished work can always be committed to topic branches which are understood to be a WIP. You can always squash commits later.


You could ask the same question of any process. Is it Necessary to:

  • use jira tickets to track features
  • attend the daily standup
  • estimate tasks in terms of story points

No! not if you are doing it some other way.

Not checking in code at least once a day is unusual.

Doing so will give your managers lots of nice graphs and show that you have at least done some typing that day.

Git doesn't punish you for checking in non functional code. You can use local branches, tags, rebases (urg) etc to manage your personal preference, but theres no reason not to check code in if it makes your boss happy


If it's not clear for you yet you should be asking your manager/mentor or other team members what is your team's mode of operation (in the commit rate sense) and you should align with it.

Advice from other answers may be good if the team works like that or bad if the team doesn't.

For example:

  • if the team is working on a branch shared with many/all other teams working on the same product (true CI) it may be more important to integrate smaller pieces faster to minimize the chances of merge conflicts which would force you to re-evaluate and re-verify your changes, maybe repeatedly. Committing a function skeleton first and following up with one of more meat-adding commits would be preferred, as long as you don't break other stuff, even if your stuff isn't yet functioning. Of course, if such partial functionality commits are accepted (and they probably would be in such dynamic environment).

  • if the team works in an environment where each commit is expected to be fully reviewed, verified and functional then obviously you'll have to follow that trend, partial commits would not be an answer. Not very agile IMHO, but still quite common in many organisations.

And you should ask your manager what is the method for checking and reporting progress for your organisation. That might actually be unrelated to the number/rate of commits (IMHO that'd be a mistake). For example tons of trivial cosmetic commits aren't necessarily "more progress" than a single infrastructure performance-enhancing commit (which might even be a lot smaller, too).

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.