
Ask HN: How often do you commit / push in Git? - obfuscatedgeek
So my company decided to try out the Scrum working methodology and hired an external consultant to get in order. The consultant was giving a talk and basic introduction about Scrum and stuff. He emphasized committing &#x2F; pushing to Git on regular basis and said he knew people who pushed &#x2F; committed like every 30 seconds. In my mind I was going WTF are you talking.<p>How often do you guys commmit &#x2F; push ?
I push in my changes when I have completely finished working on a feature &#x2F; module
======
jtfairbank
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.

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

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

------
victorbello
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"

~~~
officialchicken
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.

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

------
lsiebert
Only once so far:
[https://github.com/git/git/commit/75d2e5a7b038debee406805c9e...](https://github.com/git/git/commit/75d2e5a7b038debee406805c9e21a86e7c085789)
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.

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

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

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

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

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

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

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

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

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

------
mycroft-holmes
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.

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

~~~
GFK_of_xmaspast
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.

~~~
MalcolmDiggs
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.

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

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

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

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

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

------
Redoubts
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?

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

------
rahulgr8888
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

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

------
CiPHPerCoder
Approximately once or twice per hour.

