$ save This is a commit message no quotes
“Squash before merge” workflows seem to be more common these days and I have to think it’s mostly a push by people who do not know how to do interactive rebases and history rewrites.
If your PRs are small and you interact with git a lot using some web portal it sort of pushes you this way.
But it’s okay, I gave up trying to convince people. So I’ll just disagree and commit (pun intended).
I rarely see that documented in comments because it changes constantly, and documentation tends to be for users. An issue number can have that information, but if you're going to be tracking changes in git anyway why not use the system as designed so people don't have to hop to a different system to get a quick understanding of the commit?
There is user documentation and there is technical documentation. Both are very different. Unless you have a lib, framework or such, in which case it's more or less the same.
> but if you're going to be tracking changes in git anyway
Yes, it's a technical system for tracking changes, not documenting those changes on the developer-level.
> so people don't have to hop to a different system to get a quick understanding of the commit?
Because for any meaningful complex product you need to do that anyway. commit-messages are just the bare minimum of ways to document. Though, of course, you can make more use of it, including it in some semi-automatic changelog and such. But usually it's not worth the hazzle.
Documenting changes is part of tracking them. Yes, there is the code itself, but explaining those changes allows for following the development path. Do you expect everyone to read every line of code to understand every commit?
> commit-messages are just the bare minimum of ways to document
Single-line messages, yes. Multi-line commit messages are plenty for commit messages because they let you add more context about the changes.
I'd like to point out that it's possible for there to be multiple commits for a single issue - maybe the first one didn't fix it, or maybe there's multiple components being fixed. Simply pointing back to the issue won't give enough relevant information about each commit, it will simply say what the group of commits as a whole is supposed to do. If it turns out that fixing that issue caused others to occur, then the individual commit messages are going to be more useful for diagnosing the new problem than a single lump issue conversation will be.
I agree that there should be more documentation for a project than just git commits, I just think you're wildly estimating how useful commit messages really can be.
Do you expect everyone to read every commit? I get the impression you have the wrong focus.
Much more useful to me than the messages is the changeset file name highlighting so I can see which files I’ve touched for the thing I’m trying to accomplish right this second. Pushing resets that. So the push is based on “I’m thinking about a new thing now”. Often my commit messages are “x” because there is no cohesion to anything since my last push, I went around making a bunch of nit picks while exploring some code path(s).
If it works for me and my team, it’s the right way. Same for everyone else.
It's what I call "dumb version control" and I've observed many people not going beyond this with git: https://blog.gpkb.org/posts/git-is-a-version-control-system/
Also how do you resolve conflicts?
Or is this just your solo project with zero users so you dont have to worry about other people's commits or your own commit's quality?
The final review happens in the merge request-view on the forge. There is little reason for local reviewing. Especially when multiple people work on a branch.
> Also how do you resolve conflicts?
Editor.