I love linear git! Branches are very confusing for a nonempty set of people. For us, it is always clearer to work with explicit files in the main branch. You are implementing a new feature? Nice: just create a new file on the main branch and keep updating it until you add it to the tests, and later you call it from the main program. This system may break down on large teams, but when you are just a handful of grug-brained developers, it's perfectly appropriate.
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.
I don't understand your comment. The method that I describe only requires that the programming language ignores unused files. As far as I know, all modern programming languages have this feature.
The worst is when you move a bunch of files around in Solution Explorer and commit, maybe do a merge and push, before you realise the MSBuild/csproj files were never saved (gotta press Save All for some reason) - now you have a change you need to apply to a pre-merge commit. Good luck with that.
This feels like a lot of extra work to throw away the benefits you actually get out of version control. I would very much not like to work on this team.
