undefined | Better HN

0 pointsenriquto3y ago0 comments

> 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.

0 comments

4 comments · 3 top-level

DaiPlusPlus3y ago· 1 in thread

How do you handle major refactoring, or entire directory structure reorganisation? Stuff like that you can’t hide behind a switch.

enriqutoOP3y ago

Do 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.

bigDinosaur3y ago

I 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.

eru3y ago

There'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?

j / k navigate · click thread line to collapse