this post was submitted on 13 Nov 2024
31 points (100.0% liked)
Programming
17443 readers
248 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
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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Good analysis, there are a few things that I think area bit opinionated and there is nothing wrong with that, I just don't agree with a few things out of context. For example I agree that code on main should be buildable and testable. Code in your own branch should be for yourself and should still have commits. Also lazygit really abstracts a huge chunk of git logic while making it easier to understand.
What is important to me is that when you open a pull request the commits in that pull request, the things you are requesting to be brought into the mainline, are in a good and final form. Meaning they are actually ready to be brought into mainline. That means each of them need to be logically chunked, clearly define and communicate the intent, etc. as I outlined in the article.
Now, prior to that moment in time where you open the pull request. You can have your commits look like whatever horrible mess you want locally. Including if they are in a branch that you want locally that you aren’t going to integrate into mainline or open a pull request for.
To facilitate this refinement of commits prior to this moment of opening a pull request. I personally use interactive rebase a lot as well as use https://git-ps.sh/ to facilitate a patch stack based workflow locally.
I have found that organizing my commits according to the principles outlined in the article is extremely valuable even locally. It seems like most devs aren’t comfortable enough with git interactive rebase, etc. that facilitate refining commits as you go along. This is simply a skill issue that is well worth learning.
If you take the stance in which you say it is my PR. Whatever commits are in there are whatever commits you created, with no logical separation, no clear commit descriptions explaining the intent of each of the changes you made. You then lose the benefits outlined in the article. Tools like git bisect won’t work properly, reverting commits sucks, etc.
If you say, well what if we use GitHub to require that PR be integrated using a Squash & Merge? You still end up losing almost all of the benefits.
So I think the dividing line needs to be that if you are requesting something to be integrated into mainline, or you are going to integrate something into mainline, you should follow the principles in the article. Otherwise, you are just taking the stance that you don’t care about the values outlined in the article.
Which is a stance you can take. But those values being present or not based on your position is not opinion. That is fact, as it is provable by you simply testing out the things. So be careful not to fall into the trap of being like, “Well that is your opinion.”, and missing out on the fact that by having a different opinion you are factually losing out on the benefits.
I agree with you. They are good principles. I was just saying not every commit is merged into main and that doesn't make it less useful in the local context even if you don't adhere to those principles. Am I crazy to assume that people tend to avoid merging things into main that don't work? 😅 Git is more than a project sharing tool. I use for projects I do alone. I use it even when I don't sync it to anywhere because it's good to have save points