4 ms·
> selecting which changes (hunks, files or selected lines) to stage for commit I never understood why people feel the need do this. If you are working on a bug
by DJHenk 6y ago
> selecting which changes (hunks, files or selected lines) to stage for commit
I never understood why people feel the need do this. If you are working on a bug or feature, why put unrelated changes in that branch? It only creates confusion and probably messes up your tests too. And for what? It seems like a chaotic way of working to me.
- nemetroid 6y agoWho said they were unrelated? Sometimes a single commit is the best presentation of a bug fix/feature implementation, sometimes it makes more sense to split the work into multiple commits.
- DJHenk 6y agoI can understand that. But in my mind, if things are separate enough that I want multiple commits, then I would work on them separately. If a feature needs A, but A needs B, then I would work on B, commit that and only then work on A. Sometimes working on A will cause me to change the committed B part a little, but that's fine. At the moment in time that I committed B it was a perfectly reasonable solution that I can revert back to. You know what, typing it out I can totally see why people do it the other way. A matter of personal preference probably.
- Cogito 6y agoFor me, I often don't know exactly how I am going to do something until I have done it. Once it's done I will split the changes into commits that make logical sense, for someone wondering how the new code changes the behaviour of the existing code.
- helloguillecl 6y agoFor example I might be working on a specific feature and discover that my dev environment is missing something (For example replacing node by nodemon). I will make the change on the build script but I will not commit before testing the process for a couple of days, and certainly not before finishing the feature/bug I'm working on.