I would expect any build that I ever pulled from a repository to just compile, along with any dependencies that are required. Likewise, I would never commit anything that didn't at least compile. That is to say that there could still be known bugs or errors in the build, but at least it compiles. But this is how I do things now... I guess I sort of convinced myself for some unknown reason, that this is the way things ought to be done.When I had less experience with version control I would just check-in/commit my builds every so often just to keep track of my progress. Or in other words if I royally screwed something up I could just revert back to a previous commit (even though that commit doesn't compile). I still sort of work this way... but I at least make sure everything compiles before committing.My question is, should the committed build at least compile? Or does it not matter?
Is it acceptable to commit builds that don't compile?
git;repository;compiling
It does matter because once you're not the sole developer, you will have other people branching off the main branch. If it isn't in a working state, they'll have to fix it before starting their work, which is obviously something you don't want.What's acceptable is committing whatever you want in your own personal, private branches. You can experiment as much as you want, then once you're done, you can rebase your branch before merging into master. You have the best of both worlds: a clean public history and the possibility to revert to an older commit as much as you want during development.