Git Workflow for Agile Teams(reinh.com)
reinh.com
Git Workflow for Agile Teams
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
5 comments
If you're going to commit, run tests, and then commit again, I don't see a problem with it as long as you use git-rebase to squash those two commits together before you push them. The goal should always be to have the code in your main repository passing all tests at all times.
I've personally never worked this way, I don't commit until all tests are passing and I can't think of any time where I've ran into issues with this process. To each his own.
I've personally never worked this way, I don't commit until all tests are passing and I can't think of any time where I've ran into issues with this process. To each his own.
The "test first" extreministas write a test, write code to make that test pass, make it green, then commit. Lather, rinse, repeat. So the window for loss is exactly the work done for one small step of improvement.
I concur that it's nicest to then squash all of those tiny steps into a single feature/bug-fix chunk.
I concur that it's nicest to then squash all of those tiny steps into a single feature/bug-fix chunk.
And running tests before commit? Why not commit, run tests, then commit again? Do you really want to risk losing the work you just did because of a silly mistake (like piping something into a crucial file)?