3 ms·
> the reasonably common case very well where someone is working on changes which are constantly breaking the branch But isn't this bad practice? My grug brain
by enriquto 4y ago
> the reasonably common case very well where someone is working on changes which are constantly breaking the branch
But isn't this bad practice? My grug brain refuses to commit anything that does not pass tests. Check tests, then commit. Check tests, then commit.
You can hide your as yet incomplete feature inside an undocumented option, and work from there, without breaking anything.
- bigDinosaur 4y agoI don't see why this would be bad practice. If you complete half a feature during your work day then you may well want to commit it (and likely push it to a remote). Merging it to a branch others are working on is likely to be worse than not merging it until it is complete as it may simply be in a not working state.
- eru 4y agoThere's nothing special about commits. Feel free to commit as many broken and non-working things as you feel like. It's not much different from saving in your editor. It's in master (or your production branch etc) where you only want Commits That Work. Btw, if you are re-factoring your types, you won't be able to hide that from your compiler via a simple feature flag. What's a grug brain?
- DaiPlusPlus 4y agoHow do you handle major refactoring, or entire directory structure reorganisation? Stuff like that you can’t hide behind a switch.
- enriquto 4y agoDo it on a single commit? (or contiguous series of commits) It's not going to conflict with any other branch because there are no other branches ;) I guess that large refactorings/reorganizations are harder if you have many branches, because they will inevitably lead to merging conflicts. On a linear setup, you don't have this problem.