Do you intermingle refactoring changes with feature development/bug fixing changes, or do you keep them separate? Large scale refactorings or reformatting of code that can be performed with a tool like Resharper should be kept separate from feature work or bug fixes because it is difficult to do a diff between revisions and see the real changes to code in amongst the numerous refactoring changes. Is this a good idea?
+2
A:
Typically, I check in when I have done some unit of work, and the code is back to compiling/unit tests are green. That may include refactorings. I would say that the best practice would be to try to separate them out. I find that to be difficult to do with my workflow.
Jeremy Roberts
2009-10-02 19:55:22
+5
A:
When I remember, I like to check in after a refactoring in preparation for adding a feature. Generally it leaves the code in a better state but without a change in behaviour. If I decide to back out the feature, I can always keep the better structured code.
Duncan McGregor
2009-10-02 19:58:44
+3
A:
Keep it simple.
Every check in should be a distinct, single, incremental change to the codebase.
This makes it much easier to track changes and understand what happened to the code, especially when you discover that an obscure bug appeared somewhere on the 11th of last month. Trying to find a one-line change amidst a 300-file refactoring checkin really, really sucks.
Jason Williams
2009-10-02 19:59:13
Apply SRP to your commits. Upvoted!
troethom
2010-02-11 11:31:48
I like this method too, but it can be difficult when working directly in a large codebase shared with many developers and there's only one mainline "branch" unser source control. E.g. you're working directly in the shipping production build source branch (to which there are no other branches), and your entire feature must be finished and accepted by QA before going into source control. I know, deplorable situation, but has anyone else recently run into this sort of source control configuration?
Allbite
2010-08-23 04:01:37
+1
A:
I agree with the earlier responses. When in doubt, split your changes up into multiple commits. If you don't want to clutter the change history with lots of little changes (and have your revisions appear as one atomic change), perform these changes in a side branch where you can split them up. It's a lot easier to read the diffs later (and be reassured that nothing was inadvertently broken) if each change is clear and understandable.
Don't change functionality at the same time you are fixing the formatting. If you change the meaning of a conditional so that a whole bunch of code can be outdented, change the logic in one change and perform the outdent in a subsequent change. And be explicit with your commit messages.
Ether
2009-10-02 20:31:49
A:
If the source code control system allows it.. (this does not work in my current job due to the source code control system not liking a single user checking out a single file to more than one location.)
- I have two working folders
- Both folders are checkout from the same branch
- I use one folder to implement the new feature development/bug fixing changes
- In the other folder I do the refactoring,
- After each refactoring I check in the refactoring folder
- Then update the new feature development folder that merges in my refactorings
Hence each refactoring is in own checkin and other developers get the refactoring quickly, so there are less merge problems.
Ian Ringrose
2010-02-11 11:16:38