On 2017-05-02, at 12:47 PM, m...@jump-ing.de wrote: > > > > The Mikado method [2] is one approach to avoiding a merge hell of trying to > > do everything at once. > > Here's another method I use for several years already, with great success: > https://github.com/Traumflug/Teacup_Firmware/issues/81 Does not require to > read a book, but does require a branch to be rebase-able.
I read as much as I could about the Mikado method, and it turned out that all the basics of the method are available, either in their website, or their sample chapters, etc. Basically, you add two things to the normal cycle of improvement. - Make a change. - See what breaks. - ** Add: Make a note of what you need to do next (using a graph for visualization) - ** Add: Rollback your changes (so what you have still compiles) - Go to the next step. Since you never leave your codebase in a non-compilable state, you never get frozen. As you go through, you document more and more what's wrong, until you can fix the stuff at the end that won't break other things in the process. Then, you rewind -- possibly replaying your edits (if they were saved on a discarded branch before the rollback), possibly re-entering your edits (if there has been so much change to the code since then that you have to redo it anyways). Document it for later, and then go back to what was working, even if it worked badly. That's the key addition for the Mikado method. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
