I just see that as friction. Now a developer who is working on a new feature is reluctant to take opportunities to refactor incase their commit message doesn't match the "standard". Empower the developer and reduce friction to a minimum is my modus operandi.
Plus commit often and plan commits: with the example above the commit messages themselves are becoming a chore. Just make the message meaningful and link it to a JIRA issue or something. That's simple enough for me.
> Now a developer who is working on a new feature is reluctant to take opportunities to refactor incase their commit message doesn't match the "standard".
Having maintained a few projects on Github, I routinely reject commits that both introduce new features and fix/refactor things. Refactoring is good, but jumping on a project and changing everything at once is a strong indicator of a lack of focus. The "fix some of everything" commits usually lack tests and documentation updates which wouldn't have been overlooked if the contributor took a step away and looked at the big picture.
Adding a new feature is the main reason you'd want to refactor something. Refactoring for its own sake is nice in theory, but ain't nobody got time for that. If you are doing real refactoring in a practical setting, it's probably a situation like adding a feature that closely parallels an existing one and now some of the stuff the old feature does can be factored out.
Refactoring is often done in order to implement a new feature, but that doesn't mean they need to be done in the same commit. A common workflow is to be implementing something, realize a refactor is needed, "git stash", refactor, commit, "git stash pop", continue feature work.
- Refactor to prepare for Feature X
- Implement Feature X
Note that these can be written in parallel, but just submitted as two separate commits (guess which side of the history editing debate I come down on :) )
> I just see that as friction. Now a developer who is working on a new feature is reluctant to take opportunities to refactor incase their commit message doesn't match the "standard". Empower the developer and reduce friction to a minimum is my modus operandi.
Honestly those commits should probably be split anyway. A commit should represent the smallest 'change' which is singificant.
>Honestly those commits should probably be split anyway. A commit should represent the smallest 'change' which is singificant.
Which again may result in that refactoring never getting done. Many times I've found myself saying to myself "I must refactor this class.. But I'll just finish implementing this feature first so that I can get a clean commit with only the refactoring afterwards". Suddenly it's 5 o'clock and tomorrow I've forgotten about the refactoring need.
I can't imagine my workflow being all that special, but I never have to deal with this?
I just write new features, refactor if needed, fix unrelated bugs, etc. When I feel like it's commit-time, I cherry-pick changed chunks or lines to commit into single coherent commits. If I've introduced a new feature that required refactoring, I'll first pick all the chunks that belong to the refactoring and commit; then I'll commit the new feature and afterwards commit any bugfixes and other side endeavors that may have come up during the development of the new feature.
This is one of the reasons I don't like working with Subversion anymore. Committing, say, two changed lines in a file with many changes is nearly impossible. In 'git gui' it's a simple as selecting the lines, right-click, "Stage lines for commit" and pressing the commit button, and I'm back to working on whatever it was I was really working on.
I did this too in the past, but I've since found the convenience of 'git gui' too hard to ignore. The fact that it seamlessly runs on remote servers over X forwarding without having to install anything on the remote server really helps.
I struggle to see how this adds so much more effort?
You already know you want to refactor it so its not about forgetting to do it, and once the feature is done you'll probably have a better idea of how to refactor everything better and faster. It should actually save time in code productivity vs the extra minutes to do another commit.
Yeah, that's why I really hate rules like "all commits must have a user story attached". I'm not going to make a jira story for "function is poorly named", so if that's the rule then the code will fall to entropy.
Plus commit often and plan commits: with the example above the commit messages themselves are becoming a chore. Just make the message meaningful and link it to a JIRA issue or something. That's simple enough for me.