What if your colleagues (and yourself) have just mastered git, and they commit everything in a row?

Question

linux

The fact is that the history, as it were, should display useful information - naturally, this is a change with a brief description of a specific task. What we have now is a lot of small patching tasks, few big development tasks, and only three programmers. All this does not suit me, the repository is in complete chaos. The history does not display anything, colleagues scored on everything. there's nowhere to go, the project needs to be finished
. Initially, what do you think looking at our history? Suggest a way out of this situation, I won't be surprised if you've been in a similar situation before.. Interested in: What to commit, when to commit, and with what brief description?

Answer 1

I prefer to write commits in English. For myself, I made it a rule to start commits with the verb Add, Fix, Update, Remove, Move, Clean. Sometimes you can add the name of the module to which the commit belongs to at the beginning.
- RenderModule: Add support new feature (added a new feature)
- Fix bug (fixed a bug)
- Fix typo (fixed a typo)
- Update script (optimized the algorithm, made the function work faster)
- Move function to another class (refactoring)
- Remove (removed unused part of the code)
- Cosmetic changes (brought beauty in the code)
You can think of Russian analogues.
An article has appeared on Habré that gives an exhaustive answer to this question.
How to write comments on commits

Answer 2

in general, quite understandable and diverse commits, it is not very clear why you don’t like them?
large tasks should be arranged in one commit, but I see that you have all small ones and it makes no sense to combine them

Answer 3

They give you wrong answers and you also think wrong.
Git was just created to save the state, that is, each commit is a snapshot of the code. Some analogue of ctrl+s, if you like. Commits should not be tied to tasks, features, bugs, or anything else. You can commit at least every 5 seconds by letter, and that's fine. To manage features/bugs/etc. there are branches (not for nothing they are very light). One feature - one branch. There are at least 500 commits inside the branch, but as soon as the work is completed, a pull request is made and the feature is merged.
Nobody looks at the commit history, look at the commit tree.

Answer 4

There is only one rule: Each commit should not break the software's performance, and be completed by one small task (stage, etc.).
Another issue is that this is not always the case. So don't worry about it. The less cummit, the better.

Answer 5

As an option: an issue tracker is started (redmine for example), it describes everything in detail, and commits and branches refer to issue numbers, key points and versions.

Answer 6

Gerrit will help you.
https://code.google.com/p/gerrit/

Answer 7

Commit, not commit