I'll commit for small, incremental changes. Each commit is a semantic change to me- could be a small change applied in the same way across multiple files, or a larger change in a single file that does one thing.

I tend to push at the first opportunity it makes sense for other people to see my code, and then push again whenever I make enough incremental progress towards the feature to share. Our team has a culture of opening "in progress" PRs early and often to get feedback before we are too far along. This is great to share ideas and feedback about how things should work (instead of just about how they do based on implementation). It also helps keep the final code review size / time down.

You need at least an atomic change, i.e compiling/testing/deploying at that point makes sense.

If you just updated a typo in some comments, it could make sense to commit it and it could take 30 seconds.

Now if you are always committing as frequently, either you are working on very easy tasks with no dependencies, either there is an issue.

I usually commit whenever I've done one thing that builds and is the smallest amount of change that is still a self-contained change. For example, changes to package scripts, the code and test cases all live as separate commits. The most important thing to do is to make sure no commit breaks the build and that the commits are small enough that someone can follow what they are doing when they're bisecting in the future.

I use feature branched for everything, usually named after an issue number. I created a script that allows me to commit whenever I get a task done, not the whole feature, and that script takes care of adding the files, committing them with a message, tags it with the issue number (current branch name), and pushes to remote. That way, every time I save, the changes are saved on the remote GIT repo in case my computer dies or something.

Here's the code in case you wanted to use it:

savework()

{

  if git diff --exit-code --quiet

  then

    echo "There are no changes to save, NONE!";

  else

    echo "Stage everything for commit -------------";

    addit; # an alias for "git add -A ."

    echo "Commit all changes with message $@ --------------";

    commit "$@"; #commit is an alias for "git commit -m"

    echo "Push branch to remote --------------"
    psh; # an alias for git push origin $(git branch | grep "*" | sed "s/* //")

  fi

}

Use it like this: savework "COMMIT MESSAGE HERE"

Thank you, I'm going to modify it to:

saveallwork "commit message" --ignore "somedir/skipme.too"

I usually have just 1 or 2 files I don't want to include in a commit, but thank you again, it will definitely shave a few mins here and there.

That seems like it could generate an excessive amount of commits (or maybe not everyone saves hundreds of times per day).

Just curious -- do you squash commits when merging one of these feature branches?

I commit every time I complete an atomic unit of work. Write a 3-line test and a 3-line method that passes it? Commit.

Working on something that will take a week to be atomically complete and testable? (For instance, a major refactoring.) I'll write myself a checklist of steps and commit every time I complete a step.

As someone else said, once every 30 sec is too often, and once a day is too infrequent if you're coding 8 hours a day. When I'm in a rhythm I'll typically go anywhere from 10 min to 2 hours between non-trivial (e.g. typo-fix) commits.

I do not push every commit immediately. Once a day is a good minimum as a backup strategy and if you want to make sure you can work on the codebase from elsewhere or if you have a CI system to warn you of merge conflicts.

I'll also push whenever I complete a ticket (for long-running branches we typically have sub-tickets, or I'll push when I've completed work that someone I'm sharing the branch with can build on.) Git makes it easy to develop those units of work on separate branches, and when you merge them back to the feature branch is generally a good time to push.

Only once so far: https://github.com/git/git/commit/75d2e5a7b038debee406805c9e... is my git commit ;-)

But seriously, I commit regularly, and rebase locally before pushing, whenever possible.

It's not really about how often you commit, it's about documenting that commit as a single unit of work so looking at it it's clear what you did, and why. This often requires planning ahead of time, and even possibly creating a separate branch just for off topic commits that you think of while working on the same file.

I'm not perfect though, it's okay not to be perfect.

We use a fork model where each developer has their own fork of the "main" repository and the developer fork is cloned to the local dev machine.

Using this model I do work in progress commits as needed for different features using many different branches. Those wips and committed locally and are pushed to the remote fork many times per day for backup. For example I can do a quick push before going to lunch or meeting. I can also fetch, rebase, squash, and force push commits as desired because the only history I am affecting is on my own fork. The final merge to the "main" repository is usually 1-2 commits squashed from all the wip commits. Once that is merged I, since I am usually working on a feature branch, I can delete that branch locally and in the remote fork.

Every 30 seconds seems like a bit much, but it wouldn't be unreasonable to say I commit and push 10x a day.

> and hired an external consultant to get in order.

Recipe for disaster. :p

> knew people who pushed / committed like every 30 seconds

Pushing and committing is completely different actions in the git world.

If it's a simple fix then I try to commit and push almost instantly. If it is a large piece of work that needs several days, then I "checkpoint" it by committing at least once/day.

But I try to never checkpoint by committing something that breaks the build or unit tests. Like if my work is rewriting module A to B, then my first commit would be to add module B, second to change all dependencies from A to B and lastly to delete module A from the repo.

Depends. If it's just the beginning of a project or a side project where I'm definitely the only person working on it then I generally just use it as a backup system. If it's a more substantial project then I try to remember to commit and branch off before embarking on new feature additions, major refactors, or really anything where several hours in you could find yourself cursing and deciding that particular adventure was ill advised or is currently not worth it.

I'm not sure there's a generalizable pattern there for which has a lower actual time interval between commit/pushes but I suspect that I tend to be spammier with them in personal projects.

Incrementally, every time I make a small but significant change. I treat it like a super-save, so I can get that latest slice of work back if the disk on my dev machine dies. (The dev machine is currently a Linode.)

30 seconds is too often. Once a day isn't often enough.

> I'll commit for small, incremental changes. Each commit is a semantic change to me- could be a small change applied in the same way across multiple files, or a larger change in a single file that does one thing. - jtfairbank

I agree with that but i'd add that i'll also commit at any stopping point. Need to leave for work? Commit. Need to go home ? commit. Doesn't matter how broken the code is at that point. I'll rebase the ugly commit away. Usually the ugly commit will have a message like "INTERIM COMMIT - REBASE ME"

I'll also happily push these ugly commits to a topic branch on a remote machine for backup purposes as long as I know that no-one else is working on that branch.

I commit when I add a feature, fix a bug, anything that "feels" like an incremental step. I try to commit as much as possible so I can revert without losing much work.

I push whenever I'm about to shutdown the laptop or by the end of they day.

When developing something new, I make tons of tiny work-in-progress commits, sometimes dozens in a day, and frequently go back and squash them with rebase into a logical flow of changes, once it's more clear what that logical flow really is. I keep my WIP branches around locally for a while so I can go back and dig out the experiments I made along the way.

I prefer this over trying to get every commit right the first time. I also feel there's a nice change of pace in the process of stepping back, looking over the previous work, and shaping it into something that communicates the ideas well to reviewers.

What is the purpose of committing though? What does it additionally get you that you don't get by working in place without committing?

I find it varies with the work being done vs. relating to a discrete time duration.

In general, I try to be very atomic. As an added benefit, this makes it simpler for someone doing a git bisect later.

Fixing minor typos or copy changes across a few files could result in several commits within 15 minutes.

Working on a major feature that requires research and definition and a lot of conversation or feedback, might mean a few commits over the span of a few days.

Let's be honest, that consultant has never pushed a line of code in their life.

You're probably committing and pushing at acceptable times. Screw the consultant.

I use Scrum and I usually commit about once an hour. More if I'm just bug-fixing or correcting typos or adding comments.

Committing every 30 seconds seems like it would knock me out of my flow so often that I wouldn't get anything done.

That being said, if I'm working in the same files as someone else, I'll commit every few minutes (and so will they) so that the amount of conflicts we're creating don't get out of hand.

You could imagine some sort of IDE plugin that commits-and-pushes with automatic messages on every save, but god help you if your CI triggers on every push and your test suite is non-trivial.

Haha, yeah that would be way too much CI. We use CodeShip for CI/CD and they let you add "--skip-ci" to the commit message to skip deployment for trivial stuff.

Curious, if Scrum makes you get into this mindset that you have to commit every hour ?

Maybe, but I think it's more of a continuous-delivery thing than a scrum thing. I just commit after I add anything meaningful to the codebase (to get it out to users as quickly as possible), and that usually ends up being once an hour.

Once per feature or major change. Smallest would be a 1 liner that takes 10 seconds. Average maybe 1 hour. At the end of 1 day I commit and push to a private branch just in case my laptop bursts into flames overnight.

Commit amend for small changes.

New commit for new logical "part" of feature.

Rebase interactive when feature is "done" (in some way) to fix commit messages and squash some extraneous commits.

Push (as a branch in forked repo).

Sometimes I push before the feature is complete for backup/accountability purposes, but then I rebase anyway and push force the thing once it's done.

I commit everything that I want to be able to recover/share. If it's necessary to share (e.g. open a pull request), or if I want to have a distributed backup of my work, I'll push.

check in when it makes sense. In a feature branch? whenever you like as long as it's building often. In a dev branch directly? often enough so change gets into test regularly but not so often that your small change sets break the build our functionality other devs may also be working.

push and push regularly, in case you have merge conflicts. Get the continuous integration server building on commits and please have it email the team when the build fails too.

I commit all the time, even for minor changes and uncompilable code. But I do this on a WIP branch, which I rebase onto my main branch at the end of the day.

To my private branch? As often as I feel I need to feel safe about backing up the changes I made.

How often do you press "Save Game" during a new level?

I commit my changes as little checkpoints of the progress of my work, once a feature or a bug is done locally, I push it for people to review.

I definitely commit at the end of the day. you should have everything you did in a day on some backup other than your dev environment

Scrum is not about the how, as long as your are getting your stories done. Something seems off.

Approximately once or twice per hour.