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.
If you're great with git and this works for you, then by all means do it that way. The majority of the time, I create commits as I go as well.
But, even for me sometimes, I do work without git being top-of-mind. I do my work, do not bother with git and sort out my commits later. I find this practically essential when I'm trying stuff out because I don't know how to design the public interface of stuff, or implementation of stuff, right away. In cases like these, I'll just do my work, create temporary commits so I can reset if I screw up and clean up the commits at the end.
Another example is that, over time, I might do a small refactor on a commit I did previously. E.g. maybe I come back the day after and I think "damn that function doesn't make as much sense". I usually do interactive rebase with fixup commits for these things. However, if I did a lot of stuff like that, I find it faster to just reset and form my commits again.
Also, some developers don't care or don't know about version control. They might not create commits as they go. But maybe, they'll sort out the code in the end. Anything.
Long-story short: Do what works for you. I think what you described is good, possibly even the preferred way in a lot of cases. But there are more valid ways to get a good end result.
Another example is that, over time, I might do a small refactor on a commit I did previously
In those cases, I personally find interactive rebase more convenient than rebuilding the entire branch, but setting aside personal preferences, this is a more specific case and what works in those situations shouldn't necessarily be used as a general approach to using git.
some developers don't care or don't know about version control
A programmer not knowing their tools is not an excuse. This is hardly different from not indenting code to avoid having to learn an editor.
Do what works for you.
Yes, but with a big foot note. Personal projects are not the same as small team projects and neither are those the same as bigger team projects. Most software these days is a team effort and workflows that make it easier to make life harder for other developers won't make you many friends over time.
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.
They're good points, but I only half agree.
If you're great with git and this works for you, then by all means do it that way. The majority of the time, I create commits as I go as well.
But, even for me sometimes, I do work without git being top-of-mind. I do my work, do not bother with git and sort out my commits later. I find this practically essential when I'm trying stuff out because I don't know how to design the public interface of stuff, or implementation of stuff, right away. In cases like these, I'll just do my work, create temporary commits so I can reset if I screw up and clean up the commits at the end.
Another example is that, over time, I might do a small refactor on a commit I did previously. E.g. maybe I come back the day after and I think "damn that function doesn't make as much sense". I usually do interactive rebase with fixup commits for these things. However, if I did a lot of stuff like that, I find it faster to just reset and form my commits again.
Also, some developers don't care or don't know about version control. They might not create commits as they go. But maybe, they'll sort out the code in the end. Anything.
Long-story short: Do what works for you. I think what you described is good, possibly even the preferred way in a lot of cases. But there are more valid ways to get a good end result.
In those cases, I personally find interactive rebase more convenient than rebuilding the entire branch, but setting aside personal preferences, this is a more specific case and what works in those situations shouldn't necessarily be used as a general approach to using git.
A programmer not knowing their tools is not an excuse. This is hardly different from not indenting code to avoid having to learn an editor.
Yes, but with a big foot note. Personal projects are not the same as small team projects and neither are those the same as bigger team projects. Most software these days is a team effort and workflows that make it easier to make life harder for other developers won't make you many friends over time.
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.