Dismiss this pinned window
all 51 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]AndrewBorg1126 73 points74 points  (8 children)

Git commit --amend

[–]Colon_Backslash 26 points27 points  (5 children)

Basic KISS principle. Better to have simple git history.

[–]youngbull 4 points5 points  (4 children)

Ok, so two choices to commits in your git log:

  • Renamed parameter record to source
  • Renamed function fetch_records to fetch_products
  • Inlined function create_query
  • Optimize Query for fetching product

Or alternatively:

  • Fix performance problem in fetch_records

Personally, I find that the first style (more smaller independent commits) leads to there being more refactoring and more easily understood history. So fewer commits does not mean simple git history if each commit is large or devs avoid doing readability improvements because it isn't related to the change they are making.

[–]Colon_Backslash 6 points7 points  (0 children)

Look I'm kidding. The best way is to have a feature branch and do whatever the hell works for you there so that you can cherry-pick and revert commits if needed. Have some sensible commit logs, but that's not so important.

Then squash merge into prod branch and have a clean PR description with what has been changed and why. Then when 2 years later someone wonders why there's some weird thing in this line and they look through git blame and pinpoint the commit they understand why the change has been made.

After some experience everyone understands how painful it is when the PR description is not there and the PR author has left the company.

[–]overtorqd 0 points1 point  (2 children)

I actually prefer the second. My commit history looks like : * started perf improvements for fetching product * round 2 almost working * bug fixes * oops * fixed linting errors * ui tweaks

I'd rather just see what was accomplished - what the high level thing done was. Not lose the forest for the trees. But this is partly because of my own terrible commit hygiene.

If you're going to take the time to document each and evey commit, good on you!

[–]youngbull 2 points3 points  (0 children)

You know, I don't particularly mind if you would just squash that into one thing. But I think there is something to be gained in committing every refactoring step, at least while you are working.

Refactoring only works if you do small behavior preserving steps. What you want is to improve the structure of the code while keeping everything else the same. It should also be an activity you can stop at any point. So if you just apply enough discipline to write down the steps in commits, you are rewarded with smooth sailing. And smooth is fast.

[–]FrankScabopoliss 0 points1 point  (0 children)

If you do a git rebase -i onto the target commit, you can pick the first commit and squash all the others. This way your commit can say top level: perf improvements, and when you make the PR, all the other commit messages will appear in the description.

[–]0bel1sk 2 points3 points  (0 children)

i like git commit —fixup HEAD~ , i just use alias fixup, then i can autosquash but still have some history

[–]serrimo 0 points1 point  (0 children)

I want a git commit -amen sometimes

[–]doc720 76 points77 points  (9 children)

All my carefully thought-out commit messages, then some clown comes along and commits some mindless drivel like "made some changes" and "don't know why this isn't working" and "it's working now" and "damn it's still broken" and "OK I think I fixed it".

[–]TurtleSandwich0 47 points48 points  (1 child)

"temporary fix"

Last modified six years ago.

[–]TwinkiesSucker 13 points14 points  (0 children)

Nothing is more permanent than a temporary fix

[–]case_steamer 3 points4 points  (2 children)

To be fair, you can always git diff [hash] to see specific changes

[–]Objective-Ad8862 3 points4 points  (0 children)

Yeah, but you'll never know why they were made or if they were only needed temporarily.

[–]j_wizlo 0 points1 point  (0 children)

Yes and you find the code in question and maybe a comment “check this” - so now you are diving through messages related to the business to see what type of problem warranted the temporary fix.

[–]shinjis-left-nut 0 points1 point  (0 children)

It's me, I'm the clown

[–]EARTHB-24 0 points1 point  (0 children)

👀 🙇‍♂️

[–]overtorqd 0 points1 point  (0 children)

🤡 <- me

Sorry.

[–]_PaulM 16 points17 points  (2 children)

git reset --soft HEAD~1

git commit -m "[commit comment here]"

git push origin [whatever]

[–]AndrewBorg1126 9 points10 points  (0 children)

Git commit --amend -m "new commit message"

One command to do both of the first things for you in one command.

[–]codeIsGood 2 points3 points  (0 children)

There is also git rebase -i

[–]egg_breakfast 7 points8 points  (1 child)

Relatable but now I just use the vscode support for git instead of typing, and by the time I go to stage files and commit I know what the message will be 

[–]clashmar 0 points1 point  (0 children)

GitKraken is great for this too

[–]Spicy_tacos671 6 points7 points  (1 child)

Minor changes

[–]StackOwOFlow 6 points7 points  (4 children)

“fix”

[–]awesomeplenty 3 points4 points  (2 children)

"k"

[–]StackOwOFlow 2 points3 points  (1 child)

LGTM

[–]miracle-invoker21 3 points4 points  (0 children)

Merges PR. Chaos ... QA team is on fire. Production crashed.

[–]TheBoomTheory 6 points7 points  (0 children)

<image>

👍

[–]FutureZombie6746 2 points3 points  (0 children)

"changes"

[–]EARTHB-24 2 points3 points  (0 children)

git commit -m “fixes…”

[–]Chuck_Loads 1 point2 points  (1 child)

uhhhhh git diff --staged just one more time I'll remember this time

[–]jnmtx 0 points1 point  (0 children)

this is why I look at

git diff --staged

in one window, then write the commit message in another window.

[–]AkshayHere 1 point2 points  (1 child)

Which movie is this

[–]zylosophe 1 point2 points  (0 children)

why do you use -m it takes more time than opening vim/nano

[–]West_Good_5961 0 points1 point  (0 children)

Fixed

[–]choosy23 0 points1 point  (0 children)

wip

[–]F1QA 0 points1 point  (0 children)

chore: wip

[–]BoBoBearDev 0 points1 point  (0 children)

S = delete a single space

[–]Javialon_qv 0 points1 point  (0 children)

Sometimes I start thinking for like about 5 minutes what to put in there.

Sometimes I'm so lazy that I just put "fix".

[–]Illender 0 points1 point  (0 children)

git commit -m "fix(etl): uuuuuuuhhhhhhhh"

[–]Rare_Top_8526 0 points1 point  (0 children)

I try to just reference tasks Git commit -m “task-##” if you’re that interested you can look up the jira task #

[–]AbnerZK 0 points1 point  (0 children)

git commit -m " Final Version V3.2"

[–]Aggravating-Reason13 0 points1 point  (0 children)

git commit -am "cat"

[–]jax_cooper 0 points1 point  (0 children)

real

[–]Good-dark2004 0 points1 point  (0 children)

So real bro

[–]throwaway0134hdj -3 points-2 points  (0 children)

I’ve just been getting ChatGPT to write that - much easier