“Fix”
With 400 lines changed over 50 files
“updates”
“feat: stuff”
Guilty of this one myself.
Y tho??? Holy shit. Commits should be like functions. One thing and one thing only. Maybe a small group of files like the same change over multiple config files. 50 is insane to me.
‘Change’ if I’m feeling particularly chaotic.
git commit -m $(date)
Make a cron job for
git add . && git commit "$(date)" && git push -f
“Bits were fiddled, possibly in the right way”
My butterfly was having a bad day so I can’t be sure, sorry
See jira-blah: is my go-to. Sometimes there’s even a jira at that location/number 🤔
‘fixed odd or even function for values 600 to 950, plus other stuff I forgot to commit earlier’
Every time I commit I have to look through
git diff
, figure out what the hell I actually did, come up with something intelligent to say about jt, possibly split the commit into multiple commits if I changed multiple things, do some shuffling withgit reset
andgit add
…For some reason all my personal projects are all like 4K SLoC with 50 total commits, all of which include apologies for not doing more smaller commits
There’s a bigger issue than your commit message if you don’t even know what you just coded and are committing.
You see, sometimes I code something, go to bed before finishing it, come back, decide not to commit because then I’d have to think of a commit message and I just want to code, start working on an unrelated feature, do that for a couple days, get distracted by life stuff and put the project down for a few weeks/months, rinse and repeat, and then I finally get around to writing a commit message because I’m about to start a huge change and I want a restore point and I’m like. Okay, it’s been like 3 months since my last commit, I’m pretty sure my code can now do something it couldn’t 3 months ago but come on, I can’t even remember what I had for lunch last Thursday
I’m well aware this is terrible practice but I don’t know how to stop doing it
Commit more often. Maybe work in a different feature branch, and don’t be afraid to commit your half-working crappy code. If it’s a personal project/fork, it’s totally acceptable to commit often with bad commit names and small unfinished changes: you can always amend/squash the commits later. That’s how I tend to work: create a new branch, work on the feature, rebase and merge (fast forward, no merge commit). Also, maybe don’t jump around working on random features :P
Jumping around to random features is how my ADHD brain works most efficiently.
Good news, TDD is methylphenidate of software development!
but…but new feature shiny
Fr tho this is all excellent advice
You can help yourself a lot here by making commits every time you make a meaningful change. A feature doesn’t need to be complete to commit major checkpoints along the path to completion. That’s what feature branches are for. Commit often. It’ll help you think of messages, and it’ll help you recover in the case of catastrophe.
you can setup a on-save script to force you to commit when the number of changes is greater than a certain number from the previous commit.
I just get too excited about actually implementing/fixing something (random things that I see along the way) more than commit ceremony (nobody will care about it in my project anyway other than one random guy who gave the repo a star)
Nah, I’m that guy, I gave your repo a star for the effort, but I’m not reading your history.
it means you commit too infrequently. your commit messages should be able to describe what u just did within 10 words.
psst, git add -p
Remind me what -p does.
Edit: never mind - I see it mentioned below.
Patch add - it shows you particular changes you made, and you choose whether or not to include them in the commit. (You can then use
git stash -k
to stash only the changes you did not add, so you can test before you commit.)
I spend much time splitting them up inside visual studio by file and individual lines changed to try and separate my many simultaneous changes into several somewhat usable commits. If I was stupid enough to make some big refactor at the same time I might just have to throw in the towel… It’s really painful after a few weeks to try and pick up the pieces of what I was doing but never commited too lol.
Just use What The Commit.
You can also create a git alias:
git config --global alias.yolo ‘!git add -A && git commit -m “$(curl --silent --fail https://whatthecommit.com/index.txt)”’
Now you can just type ‘git yolo’ to create a commit!
“Make Sure You Are Square With Your God Before Trying To Merge This”
Full send.
Well such an informative reply! Thanks mate 👍
Thanks for that, I’ve been laughing like a little kid:
“hoo boy”
“lol”
“Become a programmer, they said. It’ll be fun, they said.”
I can feel those so well! :')
Psst,
git add -p
What does this?
“patch mode” - Patch mode allows you to stage parts of a changed file, instead of the entire file. This allows you to make concise, well-crafted commits that make for an easier to read history.
Highly recommend throwing
--patch
on any git commands you’re used to using. You will have the prettiest, most atomic fkn commit, I’m serious people will love you for it.I mean many people won’t care, but the quality folk will notice and approve.
Or just use a good IDE that makes doing atomic commits pretty natural.
I’ve only tried the VS code hunk stager thing, and found it cumbersome compared to command line, but if you can make a GUI work for you ya go for it. I’ve never found it worth the trouble personally
Shout out to Lazygit for letting me stage individual lines
Looks pretty neat. I like that it shows the commands it’s issuing!
You should try the JetBrains IDEs, as the other said, you can pick changes line by line graphically, when you commit, when you do a diff with another branch or when you fix conflicts. It’s much more convenient than commands and terminal text editors.
We make a singular commit per feature.
I always find this hard to follow personally.
Trunk based, eh? Yeah, we do that on a couple teams where I’m at, too. I like the philosophy, but force pushing the same commit over and over as you’re incorporating review feedback is antisocial, especially when you’ve got devs trying to test your changes out on their machines.
eh, just squash and merge. Feature branch can be messy as long as main is clean
Yay, learning!
Better yet,
git commit -p
uuuuuuuu. and you could do -m to describe the commit.
next they’ll add --push/-P.
perhaps add -r for fetch/rebase then commit.
one command to rule them all! 😈
I’m using Copilot for it right now. It works on half of the cases.
That’s about 300% better than my average!
That’s in any bloody workplace! Especially if there is o synergy between different teams.
git commit -m “changed somethings “
git push origin master
You forgot this
--force
flag.Do you always have to do origin master? I’ve seen it where sometimes just git push works and other times not.
I think it depends what branch your local version of the repo is set to. If you’re already in master then it’ll push there, if you’re in a testing branch then you can push it straight to master instead by telling it to
I just meant it not auto creating a new matching named branch.
uh in any actual company you almost never push to origin master. so I think it’s a joke.
Not with that attitude! /s
do
git commit -v
and then just summarize the diff you have in your editor in a human readable form.“blah”
Oh god I feel so called out. I wish I paid more attention to my commit messages but I’m usually too busy fixing the directory structure and refactoring. Sigh.
reminds me of what youtube was doing to firefox users for awhile.
git commit -m “break codec sync if UA = firefox/gecko”
deleted by creator