This isn’t Hugo-specific, but I figure many folks here keep their content in version control. So, what do you put in your commit message when you add a blog post?
I am importing posts from an older site, so I am trying out a bunch of different patterns, but wanted to know the new hotness all the cool kids are doing… when committing posts to their content repo.
You’re right that this isn’t Hugo specific, but here are the Hugo commit guidelines:
And here is the article much of this is based off of:
https://chris.beams.io/posts/git-commit/
NB, I’d be lying if I said I’ve been as fastidious as I should be when it comes to solid commit messages. Just ask @bep; I’ve been chastised accordingly 
I like to keep it short and descriptive.
e.g. “renewed ssl” or “head seo partial fix”
Thanks for the replies! Let me clarify: what do you put in the commit messages for publishing a new blog post? That is what I am curious about; I like to think I use best practices for commits when I am working on software, but adding a lot of content is new for me.
If you look at my recent commit log, you’ll see stuff like:
Granted I am moving over a lot of posts right now, but eventually I will be adding new content, and I am not sure what is useful to have in the commit log. Maybe something like Add $TITLE post.
I was wondering what other folks using Hugo do when they publish a blog post. 
I just use the post title (or part of it) sans the “add” and the “post” (in your log).
Guess I’m a fan of DRY.
Depends entirely on the complexity of your content. If you have a lot of posts, you could go so far as to create some editorial standards w/r/t prefixes for commit messages, but that might be a bit neurotic…
If you are the only one working on the content, you have carte blanche, but if you are working with a distributed authorship model, remember that structure is freedom.
I tend to be pedantic about my code projects (including Hugo), and I agree most about what is said here: https://chris.beams.io/posts/git-commit/
But with my blog(s) I tend to be more sloppy, as I feel the commits are mostly a reminder to self. If I worked on a team of editors, I would probably enforce something like in the above, with focus on getting a clear and uniform commit log that gives a quick insight into “what’s happening” by just browsing it.
You could follow the natural process of publishing:
I usually start my first draft in Google Keep or Vim. When it is somewhat big enough, I transfer it to my repo. I commit with message Add "My post name". I keep all the drafts committed.
I make use of git commit --amend --no-edit often.
When final copy-editing is done, and when I’m ready to push, the message is, Publish "My post name".