this post was submitted on 27 Jul 2023
17 points (100.0% liked)

Programming

13097 readers
1 users here now

All things programming and coding related. Subcommunity of Technology.


This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 1 year ago
MODERATORS
 

Was digging through a project at work today where some guy in 2014 made 100+ commits in a single day and the only one that had a comment said "upgrading to v4.0".

top 39 comments
sorted by: hot top controversial new old
[–] [email protected] 31 points 1 year ago (2 children)

git commit -m “minor tweaks”

+3,276 -4,724

[–] [email protected] 7 points 1 year ago

Bug fixes. Too many to count.

[–] [email protected] 4 points 1 year ago

I had one of those and it was two in the night and I was tired and forgot what I did and committed stuff, I dunno.

But normally I'm a good boy and prefix with the ticked id and write down the change and attempted fix.

[–] [email protected] 12 points 1 year ago (1 children)

You get two options.

Normally it’s a squashed commit of everything in a feature, with a commit message like:

[JIRA-1234] - Descriptive but Concise Name of Feature

But every now and then it’s multiple commits like:

quick fix
Ugh, fix typo
fuck fuck why doesn’t it work
Oh, I’m stupid
[–] [email protected] 5 points 1 year ago (1 children)

Followed by

fixed formatting

final formatting fix

you gotta be kidding me, fuck you, detekt!

[–] [email protected] 1 points 1 year ago (2 children)
[–] [email protected] 2 points 1 year ago

Or if you're using feature branches, rebase, squash, and force push before opening the MR

[–] [email protected] 1 points 1 year ago

Sure, but before squashing you gotta commit

[–] [email protected] 10 points 1 year ago (2 children)

Conventional commits all the way! Even if I don’t use the keywords (feat, fix, etc.) I always write the comment in imperative tense; the message should tell you what happens if you merge it.

[–] [email protected] 2 points 1 year ago

That's pretty neat. Is there a forked version that adds ticket number as a mandatory first class citizen? Cause that'd be darn near perfect.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

I totally agree.

Right now I'm on a new project with a teammate who likes to rebase PR branches, and merge with merge commits to "record a clean history of development". It's not quite compatible with the atomic-change philosophy of conventional commits. I'm thinking about making a case to change style, but I've already failed to argue the problem of disruption when rebasing PR branches.

[–] [email protected] 5 points 1 year ago

I try to follow the BLUF pattern: Bottom line up front. The first line is as short a description of the change ("Re-fixed a bug where a URL without a verb could crash the bot.") with some detail following ("I thought I caught that a couple of years back...")

I try to save the detail for the code itself: Comments describe what I was thinking at the time for context, the code is the code. I don't replicate the code comments in the commit message because having the same thing in two places means having to keep two things up to date, and that rarely goes well.

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago) (1 children)

My commits tend to be pretty verbose. Here's an example log from one of my projects.

I follow the standard imperative style for the commit title, and then I use the body to summarize any important internal changes, reflect on the overall project status (for example, what milestones this commit crosses or what other work it might enable or require), and state what I'm going to work on next. I'm sure some people find it too wordy, but I like having the commit history show lots of details about the overall status.

Edit: I always have a descriptive summary, i.e., never one word commits or similar.

[–] [email protected] 1 points 1 year ago (1 children)

you are a pro and I aspire to be you

[–] [email protected] 0 points 1 year ago (1 children)

I'm not sure I do. I wouldn't want to read all that just to find the item that broke. Might be faster to read the code.

[–] [email protected] 0 points 1 year ago (1 children)

That's why git log --oneline exists ;)

[–] [email protected] 1 points 1 year ago (1 children)

I use alias gl='git log --graph --abbrev-commit --no-decorate --date=format:'\''%Y-%m-%d %H:%M:%S'\'' --format=format:'\''%C(8)%>|(16)%h %C(7)%ad %C(8)%<(16,trunc)%an %C(auto)%d %>|(1)%s'\'' --all' It will change your world.

[–] [email protected] 2 points 1 year ago (1 children)

That is sexy. My only problem is that I tend to run my Git operations in a pretty small tmux pane on the side of my editing pane, so that layout ends up being too wide to fit well. I'll definitely keep that alias around for when I have a full screen though!

[–] [email protected] 1 points 1 year ago

Haha yea I have written a number of git and docker aliases over the years that are permanently in my dotfiles. I'm always in screen but perhaps will get into this newfangled tmux.

[–] [email protected] 3 points 1 year ago

I simply commit to master with the message "git commit".

[–] [email protected] 2 points 1 year ago
[–] [email protected] 2 points 1 year ago (1 children)

They fluxuate wildly between short and informative messages like "fixed regex validation on property A" and "I fucking hate prettier" when the build pipeline fails because I had a line that was 2 characters too long.

[–] [email protected] 1 points 1 year ago

On projects I setup I have prettier run as part of a commit hook. All files will be formatted at all times

[–] [email protected] 2 points 1 year ago

Literally about 90% of the commits I've pushed on my DayZ server's configs and mod files are just marked 'a'. The actual mod updates I almost never have made porch notes for. Trying to be a little more informative for my new D&D based Conan Exiles server.

It still looks better than how I used to name things in flash.

[–] [email protected] 2 points 1 year ago

Looking at the log of my solo project, I could say the formula of my commit message is Verb the Subject, the Verb being Added/Tweaked/Removed, etc., and the subject of what is being changed. As I'm using git commit -m 'Message' GNU Bash every time (none of the clients tend to work well for me + git self-hosting practice over SSH), I just try to make one-liners and without entering an external editor.

Although my professional experience is scarce. For most of the time, I've been creating but not maintaining my projects. My projects do not have a decent high-level structure, I do not test my codebase, I learn my code by heart and follow intuition. I tend to think in algorithms, rather than structural design patterns. Even for my newest project, the main.rs is bloated, the functions are not in the correct modules (a.k.a. files), the modules are improperly named. Alhough, I cannot believe in myself I am approaching 3.5K lines of code (separated over two repositories) but I can still navigate....

[–] [email protected] 1 points 1 year ago

I've had commits called fuck

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

I did this thing that fixed ticket #1618

For features:

I did this thing and X feature is now implemented. This closes out work for #1618

[–] [email protected] 1 points 1 year ago

Like the default Merge messages that git creates.

"Add some new feature" "Fix this and that" "Refactor XY code"

Not "Adding", "fixed", "Refactors" or anything...

[–] [email protected] 1 points 1 year ago

I try to follow https://www.conventionalcommits.org/en/v1.0.0/

For me, the need it: when production is on fire, as a responsible person, I want to be able to understand why the change of this commit has been made. Perhaps also what were the drivers of the implementation.

I also have this onliner to commit and push each 10min:

watch -n 60 'git add . ; git commit --allow-empty-message -m ""  ; git push'

But those commits would never be merge as they are to master or main. It's just if I loose work on my laptop. Worst case a git rebase HEAD~ has to be done before the PR review.

[–] [email protected] 1 points 1 year ago

I always try to capture the reasoning behind why I am making the change. I wrote about this more here https://lencioni.medium.com/the-secrets-to-great-commit-messages-106fc0a92a25

[–] [email protected] 0 points 1 year ago (1 children)

Developer Initials - Jira ticket number which includes the project abbreviation and the ticket number - brief description:

DA - HHGTTG-42 - fix question answer format

If you need details you look in the ticket.

[–] [email protected] 2 points 1 year ago

Developer intials seems a tad redundant since the commit is tied to author(s). But I guess it is only 2 extra char

load more comments
view more: next ›