←back to thread

35 points Terretta | 1 comments | | HN request time: 0.202s | source
Show context
r1cka ◴[] No.45772653[source]
I think people worry too much about branch names. Feature branches are usually ephemeral. Prefix your branch with your personal identifier so I know who is primary on it and worry more about the commit message which will live on indefinitely.
replies(5): >>45772677 #>>45773377 #>>45773466 #>>45774133 #>>45774578 #
focom ◴[] No.45774578[source]
Commit message should be ephemeral too. Squashing after a PR should be the default. Only at that moment does the PR/Commit message matter.
replies(2): >>45774768 #>>45780891 #
bavent ◴[] No.45774768[source]
Hard disagree here. GitHub does encourage this sort of thing, but even there for my PRs to be easily reviewable, I like to keep my commits organized and with good messages explaining things. That way the reviewer can walk the commits, and see why each thing was thing was done.

I also like it for myself, when I’m going over my own PRs before asking for a review - I will often amend commits to ensure the work is broken down correctly, each thing that should go together, does.

In a way, stacked PRs are just a higher-level abstraction of this too - same idea, keep work that goes together in the same place.

replies(2): >>45774846 #>>45776441 #
freedomben ◴[] No.45774846[source]
Fully agree with you here. Blunt squashing is a bandaid to the problem of lazy commits. Commits should IMHO be specific and atomic. Like fixing one bug or implementing one feature. Obviously there are cases where this ideal isn't practical, but the answer is still not squash everything, it's to think for 10 more seconds about the commit and do your best.
replies(1): >>45775032 #
bavent ◴[] No.45775032[source]
Yeah, I think over use of GitHub, which seems to encourage squash-merging, has led to this where a lot of people I’ve seen treat a PR as essentially one commit - because it ends up being one in the end.

If you keep your PRs small I guess the end result is the same, but even then I like things in individual commits for ease of review.

replies(2): >>45775099 #>>45776452 #
focom ◴[] No.45776452[source]
> If you keep your PRs small

Its not a if. it's necessary for the sake of people reviewing your code. Unless you work alone on your pet project and always push to master you never work alone.

replies(1): >>45777785 #
1. bavent ◴[] No.45777785[source]
Right, small PRs are great. And they are even better with a nice commit history for me to follow. One does not exclude the other.