| ▲ | lucasoshiro a day ago | ||||||||||||||||
> Maybe consider putting your energy into a good documentation inside the repository. Commit messages are documentation. If you have a good commit history you don't need write tons of documents explaining each decision. The history will contain everything that you need, including: when and who changed the code, what was the code change and why the code exists. You have a good interface for retrieving that documentation (git log, perhaps with -S, -G, --grep, -L and some pathspecs) without needing to maintain extra infrastructure for that and without being cluttered over time (it will be mostly hidden unless you actively search that). You also don't need to remember to update the documents, you are forced to do that after each commit. And that's not a hack, Git was made for that. | |||||||||||||||||
| ▲ | 1718627440 a day ago | parent [-] | ||||||||||||||||
A surprisingly large amount of devs, do the work to record data into a VCS (probably because they are told to by colleagues or superiors), but never seem to use them. Then they tell you that generating proper commits isn't all that important. Well, that's because they never actually use the VCS. By my book, only generating commits isn't really using a VCS, that is the information generation part, you also need to do queries on the collected data, otherwise yes it would be quite useless. | |||||||||||||||||
| |||||||||||||||||