Front end developer specialising in JavaScript and React. Experienced in all aspects of modern front end development. Passionate about making accessible, secure and performant software.
Fair enough. I think both points of view have valid points. In my experience, most developers don't value commit history very much.
In fact, I believe I do a very good job at it, but I don't value it super highly either. There are tons of things developers need to worry about that impact the business in different amounts. E.g. security, accessibility, knowing your framework, language, writing clean code, tests, etc.
All of those have a huge impact on the code. However, commit history has a minor impact. How often do you read the commit history? How often do bad commit messages affect you in your work? At least in my personal experience, the answer is very rarely. Also, in every codebase I've ever worked, the commits were awful.
For that reason, my point of view is that doing okay with your commits is better than doing nothing. I appreciate any commits that my coworkers create that are okay. They don't have to be perfect. Anything they use to achieve that is a good thing. A small tip doing your commits in the end is probably easier to learn and implement than "always do great commits as you work".
Having said that, I still agree that the method you're describing is preferable most of the time. But, it would require the developer to know git fairly well in my opinion, which might be a luxury considering everything else they have to learn.
I totally agree with you that the perfection of git commits should not be prioritized over other more impactful skills, an average knowledge could be enough. Some branche organizations can even mitigate bad commits to pollute the main history of an project.
But the title of the article states that is "A Better Git Flow". It could be an alternative way of work, maybe easier for beginners. But better is quite questionable. I believe that rebase should be the way to go. Many beginners at git sees rebase as a monster, when IMO is just a good tool that requires time to understand.
Also, denying the importance of a good commit message only typing WIP, sounds like a nightmare to me. Checkout this pattern of committing, I really appreciate it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Fair enough. I think both points of view have valid points. In my experience, most developers don't value commit history very much.
In fact, I believe I do a very good job at it, but I don't value it super highly either. There are tons of things developers need to worry about that impact the business in different amounts. E.g. security, accessibility, knowing your framework, language, writing clean code, tests, etc.
All of those have a huge impact on the code. However, commit history has a minor impact. How often do you read the commit history? How often do bad commit messages affect you in your work? At least in my personal experience, the answer is very rarely. Also, in every codebase I've ever worked, the commits were awful.
For that reason, my point of view is that doing okay with your commits is better than doing nothing. I appreciate any commits that my coworkers create that are okay. They don't have to be perfect. Anything they use to achieve that is a good thing. A small tip doing your commits in the end is probably easier to learn and implement than "always do great commits as you work".
Having said that, I still agree that the method you're describing is preferable most of the time. But, it would require the developer to know git fairly well in my opinion, which might be a luxury considering everything else they have to learn.
I totally agree with you that the perfection of git commits should not be prioritized over other more impactful skills, an average knowledge could be enough. Some branche organizations can even mitigate bad commits to pollute the main history of an project.
But the title of the article states that is "A Better Git Flow". It could be an alternative way of work, maybe easier for beginners. But better is quite questionable. I believe that rebase should be the way to go. Many beginners at git sees rebase as a monster, when IMO is just a good tool that requires time to understand.
Also, denying the importance of a good commit message only typing WIP, sounds like a nightmare to me. Checkout this pattern of committing, I really appreciate it.