As I work more and more with git and GitHub I have become really interested in the version control processes of individuals and teams for developing software.
My next thought is about if the git log of commits should be a real time representation of how long the work actually took you to complete? Does it matter? There is probably a multitude of better ways to check this work, but does anyone do this?
Let me give you an example. Let's say I am building a static site. I will have an HTML file and a CSS file. I start working on the HTML file to build out the scaffold of the markup and start to putting in placeholder content. I am making commits as I go.
Should a git log be real time? Should it show how long I actually took to do this work?
Now, let's say I have made changes to multiple files like CSS and Javascript files. The CSS is setting up styles and the Javascript is functionality. I committed each in their own commits. This way styling changes and functionality could be rolled back, if needed, on their own without undoing all of it.
But, when I did this work I wrote all of the CSS and then went straight to the Javascript before creating the commits. Once I was done with the Javascript I did a commit or the CSS and then did another commit for the Javascript file.
This makes it look like in the timestamps that the CSS is put in and then seconds later the JS is put in.
Is this an issue for some folks? Does it appear to some that the JS only took seconds to write? Should there be a difference in timestamps to show how long the JS work took? To do that I would need to make sure to do the CSS work and commit it before moving on to the JS work. I might forget to do this and end up with all of the files changed before I realize I should have committed.
Is this a big deal?
Top comments (12)
I would never force, or hold off on a commit in order to make the timestamps appear more accurate. I'd only commit in a way that makes sense in terms of 'save points' and logically grouped units of work.
If the commit timing happens to be an accurate reflection, then great, but I wouldn't let that lead my thinking.
I agree. I have felt the pain of having to track my time at work down to the minute to show productivity and it always left me feeling like I wasn't doing my best as I had the tracking process in the back of my mind keeping me from concentrating fully. It is really tough when we need to track how much we are working, but that becomes work in itself.
Git doesn't seem like the place or tool to be doing any measuring on how much work is getting done. Thanks!
I like this comment, it's how I do it, too. Unfortunately github does not represent my logical reordering of commits in its PR view.
Like the topic!
I just see commits a little units of work, less like people in a queue, more like bolts in a car. So personally I don't place any importance on timestamps, and am only concerned about commit ordering in so far as merge conflicts and other forms of clobbering.
Also I make extensive use of rebasing and that resets commit timestamps, so a lot of my work appears to have taken a day of thinking time and 0.01 sec to code up, looking at a git log anyway.
Thanks! Very good point. Git is a powerful tool that allows us to do a lot. In many ways the metadata can be altered by our actions to change the picture of how the work was completed that doesn't reflect the reality.
I guess answers will be related to your view on what a git log should represent in your project: is it an accurate account of the work that was done, or a story of how the code was written? The difference is subtle but important for this discussion.
In my practice, I prefer pull request commit logs to show an accurate account of the work that was done for the sake of providing development context to reviewers. But I prefer the commit log of the project as a whole to tell a higher-level, cohesive story of how the project changed over time; as such, I am often squashing, rewriting, and reorganizing my feature branches prior to merging them into the project trunk.
Given this sort of workflow, which constantly changes commit SHAs and timestamps, I never look at commit timestamps except to determine when a bit of code was introduced to the code base, and rarely does anything more granular than "day of month of year" matter to me.
So I tend to view commit timestamps as capturing the birth of code as witnessed by the codebase rather than as an accurate representation of when it was written. From this perspective, I don't think the addition of "real-time work tracking" to the project history is useful to me most of the time.
Now, all of that said, I love the idea from a personal productivity and effectiveness angle 😍 I've thought many thoughts about ways to encode more of the human factor into commits for later analysis. It's really fascinating and also poses terrific challenges!
There's a difference between real-time work tracking for a project, and for a person. And there's a problem with how to define "work" in both cases: how do you capture/represent the effort that went into every commit? This includes rewriting, testing, debugging, begging the tiny gods of StackOverflow for help, going for a walk to think through a problem, ....
And how do you also factor out time spent distracted? Or do you include that metric as well?
Personally, if we could come up with a clear definition of capturing "real-time work" into a timestamp, I would use it to simply get a better idea of how long it took me to do a task vs. how long it felt, which I'm sure I could use in a number of ways. But I wouldn't obsess over the exact values given how much my mileage varies by circumstances 😄 Nor would I consider it useful from a code history perspective.
Thanks so much for the thoughtful response. I love this. I agree that from the often used features of git the timestamps will change frequently. Like most things with working on a team a workflow would need to be agreed upon so that any kind of baseline could be established.
I also really like taking a step back to look at it from a couple of angles. Personal or individual productivity measuring is super hard and there is so much that is difficult or impossible to measure in any meaningful way. The process of measuring often is so much work in itself it takes away, or at least feels like it does, from one being productive.
This is a great example of the many ways work can be measured and the importance of a team of people agreeing on how that measuring is done and what is measured when determining how to be effective at their work.
Here's a great project that may be of interest:
github.com/git-time-metric/gtm
It doesn't alter your commits. Instead, it keeps track of the time spent working on files and adds those metrics when you commit the changes.
Timestamps will only be valuable in legal disputes. Time of work is not a intended use of timestamps (otherwise there would be a start time).
I view git as a Communication tool and it should focus on communicating changes.
Git is a Communication tool
Jesse Phillips ・ Dec 12 '18 ・ 2 min read
IMO: Nope.
If I need to track time, I will use a time tracker.
Sometimes I will work on one thing, notice something different in a file I am working on, and will fix it, then make a partial commit.
Sometimes I work on a Vue component which needs to fetch some data. I will design the component, mock the data, then add a vuex action to call an API and save the data to a vuex store, commit the changes to vuex (because the store can work without the component, but the component will not work without data, and I try to avoid committing test data whenever possible), and finally commit the ones to the component later.
Find a way that makes you a more efficient coder, and don't set arbitrary rules for yourself. Ensuring that I work on things in a very specific order rather than when I need them would not make me more efficient. Committing incomplete or broken code would not make me more efficient. (Occasionally, that can't be helped; I may make a broken commit and push it just so I can resume work on another machine).
That said, I like doing things my way. If you find another method more suitable for your workflow, that's great.
Thanks for sharing! This very much looks like my workflow and was part of why I asked this question. I sometimes go from one thing to another because of my process that when all completed builds out one thing, like a new feature for example. It would be really hard to commit things and work in a way to allow for this. Also, like others have noted there are tools in Git, like rebasing, that will change this metadata and make it no longer reflect reality and looking at the timestamps wouldn't matter then.