Is daily commit and push necessary for managers and supervisors to check my progress and productivity?

Question

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.

Thanks.

---

Update

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.

Answer 1

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.

Answer 2

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 them¹, 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.}

Answer 3

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?

Answer 4

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.

Answer 5

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

Answer 6

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