I noticed that the number of my commits greatly exceeds the number of commits of other people in similar projects (one not the most difficult project in the world took more than 300). This, of course, is not my main problem in life, but I got the impression that I was doing something wrong, and this could make it difficult to dig into the history of the project.

I make a commit every time a new feature is added to the project, and after that it comes to a working state, and it doesn't matter what size the feature is a simple grammar correction, bugfix, implementation of some new functionality (the latter can be broken down into several commits , but after each of them the project should be workable), and if I corrected css, I replaced the disgustingly curved text with a simple curve and reassembled the action in the controller - this is, in my philosophy, there should be three commits, because they affect different e unrelated parts of the project. As a result, on the one hand, I can get almost any cast of the project and it will work at any time, on the other - I get a bunch of commits like 'Typo fix', 'CSS fix', 'Microfix', which, probably, could not exist.

In short, how to do?

ps One of the probable reasons for the situation is that I almost never use branching. I myself am a fool.

upd. More precisely, to formulate the question - should the introduced features be atomic (one commit - one feature or bugfix), or you can give a damn?

  • @Etki, it’s not clear whether you are describing a working product or just being developed and working on it as a team (i.e., the work of friends' people depends on it) or alone. - But in general, you yourself can figure this out? (Obviously, the new man will not be able to. He will probably make a brunch and continue from scratch.) - avp
  • @avp, in this case alone developed the project. In a normal team, I have not yet had time to work. - etki
  • @Etki, if it is for myself, then why commit every sneeze? Do it when you get the next working version (or when you seriously doubt the correctness of the changes and suspect that you have to roll back, but here, it seems, you need to do a brunch). Actually (if there is no normal project, and when working alone, a modified project is almost always not there, many details remain "in the head") you still get many versions, because did something and it seems - that’s all! And in a day or two, you realize that no, you need to change this and this and this one ... - avp
  • It seems to me that a bunch of commits are quite normal, there is a problem number in the bugtracker for grouping them by their meaning. - zb '
  • @avp, to get away from it as much as possible:> I hate commits when the changes are piling up, then broads - a global commit with a cloud of conflicts merge. - etki

2 answers 2

According to commits, I have the following rules:

  1. A commit should compile without errors.
  2. A commit should designate at least a new feature / class / method / bugfix.
  3. Or at least a commit should mark the end of the working day.
  4. A commit should not delay other team members, for merge is evil (sometimes necessary).

From which it follows that if I am engaged in a project, then at least 1 commit per day I have to do. I can not tolerate commits when changes are piling up, then women - a global commit with a cloud of conflicts merge. On the other hand, more than 2-3 commits per day are unnecessary, well, except at the request of the comrades.

Update for git fans: in this context, a commit is not a commit to a local turnip, but a Gitovsky push to a global turnip.

  • Learn how to use branches already :) I do not have to compile the local dev-branch without errors, and with high probability there are errors. For a common dev server, there is a testing branch in which everything supposedly works. And if all the tests are carried out successfully, this branch is merged into the master, from which the production is updated. - nolka
  • one
    If there are commits in your branch (except for the last one) that are not compiled (and this is intended), then I have bad news for you. - KoVadim
  • This is quite normal :) This is not a production branch :) - nolka

You are doing everything right :) And go, finally, to git:]

Do you want a new feature - make a branch in which you implement a feature, then merge it into virgins, test, and further on the list ...

No need to limit yourself in the number of commits. Just you will have a more detailed story in which case :)

  • And here git? - Barmaley
  • 2
    There are normal branches there :) - nolka
  • 2
    @nolka, I work in the gita, CVS here does not appear as the name of a specific system, but as a generalization of all systems. I just thought that the problem described is git independent . - etki
  • one
    oh, you probably wanted to write vcs:] CVS put me in a stupor :) - nolka
  • @nolka, if you mean branches in a local repo, then I agree, they are useful there. But from the point of view of git-push to global repo is equivalent to commit in CVS, so here it is necessary to compare git-push vs. CVS / SVN commit - Barmaley