Programming

17418 readers

24 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Git Commit Creation (drewdeponte.com)

submitted 3 days ago by drewdeponte@programming.dev to c/programming@programming.dev

7 comments fedilink hide all child comments

Git Commit Creation

This is an article in which I explore the details and thinking that goes into how you should create git commits, and why. I like to think of it as the article I wish existed when I was just starting out over 20 years ago.

I wanted to cover all the things that you should think about at a high level. That way it at least could work as an entry point to deeper exploration of the particular areas if the reader isn’t completely sold or they want to just gain a deeper understanding. While at the same time trying to provide enough details to show why and how these choices are valuable. This is always a tricky balance.

Anyways, I would love any feedback on thoughts on how this could be improved.

Thanks

you are viewing a single comment's thread
view the rest of the comments

[–] sorter_plainview@lemmy.today 3 points 3 days ago (3 children)

So this bit confuses me. The article says in the intent and scope section that the entire process of bug fixing, in the included example, is literal bug fixing, clean up toggle, correct lints, correct duplication. That point to linting issues.

The earlier section says that a commit should be 'buildable' and 'testable'. So if there are linting issues, the commit won't satisfy this criteria right?

What am I missing here?

[–] drewdeponte@programming.dev 2 points 4 hours ago (1 children)

In the example I provide the project that the PR was made for doesn’t have the linting passing as a build requirement. But that is irrelevant to the point I am trying to make which is to split things out base on those singular intents. Do you think that point was clear?

Maybe I should change the example so that it isn’t based on linting which can be part of the build requirements but doesn’t have to be.

[–] sorter_plainview@lemmy.today 1 points 3 hours ago

Aah. I assumed linting was part of the build also. My bad. I did understand the idea you were mentioning. Just that assumptions kind of threw me off.

I wanted to ask something related to that. As you mentioned, git takes a snapshot of the repo on every commit. So splitting up the bug fix and other activities means you have 3 or 4 commits instead of one. Let us say we are dealing with a very large repo. This does not look ideal in that context right? So do you think the way you proposed is only suitable for smaller repos?

load more comments (1 replies)