This doesn't handle the reasonably common case very well where someone is working on changes which are constantly breaking the branch for everyone else. They should have their own branch and be frequently rebasing/merging so as to not disrupt others.
Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be broken, the production branch should ideally never be in a state that cannot be deployed.
That said, keep the branches limited and try to keep them 'linear' in the sense that you don't want to be merging between 100 different non-main branches in some byzantine nightmare. Perhaps encourage merges only to the development branch and then rebranching.
> Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be broken, the production branch should ideally never be in a state that cannot be deployed.
Well, why don't you simply copy the code into a new directory and commit that? Then you can do whatever you want in the scratch directory.
To me that seems messier than a new branch. For one, how are others to know my files are test/scratch/feature branch files? I'd have to use a naming scheme, and some kind of other signal to make sure nobody imports them before they're ready or mistakes them for deployable files - and at that point I'm just replicating a branch!
> and at that point I'm just replicating a branch!
Yes. My entire point is that you can always replicate branches with actual, explicit files, and that this is a good thing to do because files are (very often) better than branches. Files plus some editor discipline are essentially equivalent to branches.
Files+discipline are better than branches, according to standard unix philosophy: (1) everything is a file, (2) protocol not policy.
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.
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.
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.
Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be broken, the production branch should ideally never be in a state that cannot be deployed.
That said, keep the branches limited and try to keep them 'linear' in the sense that you don't want to be merging between 100 different non-main branches in some byzantine nightmare. Perhaps encourage merges only to the development branch and then rebranching.