55

Since i switched to git from svn i started make more commits every time i recompile and my tests pass i commit my work. In the end i end up committing function by function.

I also track some other projects using git like emacs,wordpress etc. I see that they do not commit that often. So i am wondering how ofthen do you commit?

Hamza Yerlikaya
  • 49,047
  • 44
  • 147
  • 241

11 Answers11

64

The guideline for the Git project itself (and the Linux project, AFAIK) is one commit per "logically separate changeset".

This is a little ambiguous, but you probably don't want to commit every few days if you're working on a project constantly, and you probably don't want to commit after every function change - if you've edited several functions in several different files, you want to commit all of the related functionality together if you can and provide a useful commit message with it. All of the code modified in each commit should be related, but it can (and probably should) certainly be across several files.

What you probably want to keep in mind is in code reviews. If someone is trying to decide if they should merge your work in, it's much easier for them to process the work being introduced if you have each commit logically contained and separate from each other. That lets you (or others) cherry pick work effectively - if you have three commits with one function modified in each but they're all coupled somehow - you can't apply one without the other two without breaking the codebase - then they should probably be squashed down to one commit.

Scott Chacon
  • 2,756
  • 19
  • 14
  • 11
    Als you would want for each comitted version to work correctly (this help with bisecting for finding errors). – Jakub Narębski Jun 25 '09 at 10:48
  • 3
    if you own the project, commit whenever you feel like it. If you're editing someone else's project, commit when the patch is finished – Tyler Gillies Jul 29 '11 at 09:39
  • Excellent point on code reviews, if someone looks at the commit they should be looking at a single decision or change, that change can be in one or a number of files, but they are related by a single functionality or improvement. – ChristoKiwi Dec 06 '15 at 04:22
26

I also track some other projects using git like emacs,wordpress etc. I see that they do not commit that often.

One of the nice things about git is that you can commit as often as you like, and then when you want to do an upstream commit you can squash several related commits together into one nice clean commit using git-rebase.

kenm
  • 23,127
  • 2
  • 43
  • 62
  • 22
    It should be noted that git rebase, while awesome, is a very dangerous tool if you are not careful. – baudtack Nov 17 '09 at 00:11
  • 4
    @baudtack: Not at all. Rebase with impunity, and if you completely botch it, just use `git reflog` and `git reset` to get back to where you were! – Zaz Aug 08 '13 at 21:40
  • @baudtack Any arguments for your statement? (I don't use it, but curious for the sake of others). – MasterMastic Feb 18 '14 at 00:00
  • @Ken So My comments come from older git usage. But where rebase can burn you hard is if you try to rebase something that has been pushed to an external repo that other's use. Doing that will cause fire to come down from heaven and burn you as a warning to all others who would do such a terrible thing. – baudtack Feb 19 '14 at 17:30
  • 4
    `git rebase` is not dangerous at all. If you want a easy safety net before doing the rebase, create a backup branch of current HEAD with `git branch branchname.bck`. If you're not satisfied with the rebase, return to the previous state with `git reset --hard branchname.bck`. The rebased commits are still around if you want to return to the rebased version, but since they're stored as unreferenced objects, you'll need `git reflog` or `git fsck --no-reflogs` to find the correct sha1 values. – sunny256 Sep 23 '14 at 08:59
  • 2
    Please, let's all stop the "rebase is very dangerous" meme. Dangerous? No. Nearly Magic? Yes! Divergent shared history is a pain, yes. But rebasing one's own branch for clarity of commits should be encouraged! e.g. http://jeffkreeftmeijer.com/2010/the-magical-and-not-harmful-rebase/ – spazm Mar 10 '15 at 23:08
14

In the end i end up committing function by function

Do not forget you could rather "git add" function by function, making only one commit:

  • once all the functions are written or fixed for a given task
  • or once you realize the current function is too large/complicated to be part of a commit any time soon: you can then commit what is currently "on stage" ("git added"), which would not include your current modifications in the working directory.

Then, the number of commits can be related to the purpose of the branch:

  • local branch: go crazy, commit anytime you want
  • "public" branch (one that you will push):
    • for a local repository (for selected group of people): you could regroup at least the very small "intermediate" commits
    • for a public repository (for all developers, or other projects to see): you can make an interactive rebase in order to regroup your commit by "activity" or "task" in order to make those more readable.

In short, "publication considerations" can, in a DVCS (as in "Distributed"), guide you as to make the proper number of commits for the right reasons.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
10

The more you commit the easier it is to find bugs with git bisect

baudtack
  • 29,062
  • 9
  • 53
  • 61
8

As soon as tests pass, or when a unit of functionality is added/deleted/modified.

Alan Haggai Alavi
  • 72,802
  • 19
  • 102
  • 127
3

It really depends.

What I do is I commit locally often, as it sounds like you're doing, but I only push my changes when I've accrued several influential ones.

This ensures that I save my work, but it also doesn't clutter the repo for other users.

samoz
  • 56,849
  • 55
  • 141
  • 195
  • Well, you can run "git add" often to save your work, but only commit when a feature is complete. – Marius K Jul 21 '11 at 12:15
  • 2
    But if you don't commit those local changes, you can't go back and review your own work. – samoz Jul 21 '11 at 18:02
  • "it also doesn't clutter the repo for other users" - this was a while ago, but, you want to get your changes into trunk asap, so others can integrate. As always tests are present and passing before every commit. – ocodo Jul 27 '22 at 01:39
3

Our business needs have us commit to the unstable branch when the program compiles, and commit to the stable branch when it passes unit testing and has been reviewed by the customer (while it was under the unstable branch).

Andrew Sledge
  • 10,163
  • 2
  • 29
  • 30
2

I commit after I add or change functionality and have a successful test. Or when I'm going to be switching from my desktop to laptop and want to pull down the code, I'll commit and push.

1

What you are doing sounds about right to me. Any time you have a working setup that you want to be able to go back to if you mess something up is a good time to commit. If you have a nice setup where running regression tests is quick and easy, I could see that being fairly often. For me, I'd be lucky to make one a week.

T.E.D.
  • 44,016
  • 10
  • 73
  • 134
1

1- Commits should be frequent; committing code to the remote repository (not just locally) should be done frequently so that the code is backed up just in case it is somehow lost; this happens more frequently than you'd expect so, pushing your changes by end of day is a must to avoid potential rework and to ensure the remote repository is always up to date.

2- Commits should be granular and therefore should not include too many changes to the code base. Commits with too many changes are harder to revert and cannot be used as a reference from a "history" perspective as commit messages would have to be too long in order to cover the full scope.

3- Commits should have a proper title; title should start with a capital letter and should not end in a period. Generally, titles should be short and to the point.

4- Commit descriptions are optional but are nice to have.

Alaa Moneam
  • 509
  • 5
  • 10
-6

I commit pretty far apart. git isn't meant to "backup" your code, you should be using tarballs or dropbox or something to ensure you don't lose code.

If you don't commit very often you can better tell exactly what should go in what commit and it gives you a smoother history than 50 commits with

"oops", "damn", "forgot that file"

you can rebase, but if you never stage/commit in the first place, theres no need to undo your work

Tyler Gillies
  • 1,857
  • 4
  • 22
  • 31
  • 15
    I'd consider this an anti-pattern. Commit early commit often locally, then squash before pushing upstream. You DON'T want to lose your work. Backups are for hardware failure, git is to save every logical change you make in a way that can be audited and reverted easily. – John Gibb Aug 23 '11 at 15:37