I commit frequently and rebase to make it nice afterwards - which seems to be a common pattern. For commits that I know at the time need revisiting (partially c

I commit frequently and rebase to make it nice afterwards - which seems to be a common pattern. For commits that I know at the time need revisiting (partially complete feature/tests don't work/solution works but needs heavy refactoring) I'll prefix the commit message with "WIP" so I have a hint when I come back to it. When the problem is finished, I go back and neaten up the history into a smaller number of logical commits that would make as much sense as possible to someone reading the history. Tests (in my opinion) need to run continuously during development. I usually have tests run on file change - either in a terminal window or IDE. They also run on each commit when each branch is pushed. If you have no option other than to run a test suite that takes hours, that needs fixing. You don't need to run all your tests during development, but pragmatically you need to run enough of them to give you some confidence that you haven't broken things. Some options you might have: * Separate fast and slow tests (e.g. unit tests and integration tests). Run the fast tests frequently as you develop, and use the slow tests to sanity check what you're doing from time to time * If there are no fast tests (e.g. everything is almost an end to end or full integration test), write some faster tests just for the feature you're working on and run those. It doesn't need to be perfect; just lay down a start that you and your team can improve on * If all your tests are fast, but there are just a lot of them and they're so abstracted from the layer of code you're working at you can't tell which are relevant, you can add tracing statements to define a subset of tests that hit the codepaths you're changing. Run the small subset regularly. * Spilt up your codebase - this doesn't have to be into trendy microservices if your problem domain doesn't support the use case. But you'll almost certainly be able to pull out modules or libraries into separate repos that have their own tests. Version them semantically. As a discipline, we work across a huge range of problems and I'm wary of making assumptions about yours; but slow tests have a massive impact on how quickly you can deliver in my experience.