This is a terrible idea. At this point, you're losing many of the benefits of git because you're no longer committing your changes in logical groups as you write them, nor are you automatically making sure each commit represents a working state of your system by trying it out as you go.
Instead, you'll have to manually review your changes with a much higher chance to miss things, commit them and ideally stash all uncommitted changes to test the in-between state of your application.
Even worse, you're missing out on the accountability of commit timestamps, so you can no longer see when you made what changes.
And on top of all that you're now writing commit messages long after you made the corresponding changes, so you might be forgetting or misremembering important details that could be worth documenting.
As for the problems you list:
The first problem we've already discussed is that some commits may contain incomplete work when you simply commit as you go
That's just not true. If you use git properly, you won't be dealing with this problem. This only becomes an issue when you can't use git in the first place, in which case all the problems I've listed above will only be worse for you.
For example, what if you've been asked to review a recent PR in which the author states that, on top of adding a new feature, they fixed an unrelated bug as well [...] Looking at each commit individually does not illuminate which changes pertain to the bug fix and which are for the new feature
Once again, this is a purely made up issue. If a developer isn't capable of structuring their commits in a way that makes it clear what each of them does, then their problem goes far deeper than some fancy workflow and they should sit back down and actually learn how to use git. There's many good tutorials out there on how to make good commits.
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.
This is a terrible idea. At this point, you're losing many of the benefits of git because you're no longer committing your changes in logical groups as you write them, nor are you automatically making sure each commit represents a working state of your system by trying it out as you go.
Instead, you'll have to manually review your changes with a much higher chance to miss things, commit them and ideally stash all uncommitted changes to test the in-between state of your application.
Even worse, you're missing out on the accountability of commit timestamps, so you can no longer see when you made what changes.
And on top of all that you're now writing commit messages long after you made the corresponding changes, so you might be forgetting or misremembering important details that could be worth documenting.
As for the problems you list:
That's just not true. If you use git properly, you won't be dealing with this problem. This only becomes an issue when you can't use git in the first place, in which case all the problems I've listed above will only be worse for you.
Once again, this is a purely made up issue. If a developer isn't capable of structuring their commits in a way that makes it clear what each of them does, then their problem goes far deeper than some fancy workflow and they should sit back down and actually learn how to use git. There's many good tutorials out there on how to make good commits.
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.