On 2017-05-05, at 11:47 AM, Markus Hitter <m...@jump-ing.de> wrote: > Am 05.05.2017 um 19:43 schrieb Michael: >> 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. > > Sounds very complex and a lot more work than rebasing that branch in small > steps. > > "Make a change" = rebase by a commit or two > "See what breaks" -> still the same > "Make a note" and "Rollback" = do an interactive rebase. > > Advantage of rebasing: no need to document anything, fixes go straight into > the commit introducing the breakage. Like "fix and forget". > > Another advantage: you can see what the last commit at the branch point > changed. Usually changes which depend on each other or make sense when > applied together, only. With a huge diff/merge attempt there is no such > information available, everything is hidden in a large haystack. > > Yet another advantage: fixes here often break something there and replaying > the whole branch to be merged after each small change makes sure such > regressions get exposed immediately. When hackers memory is still fresh about > what was changed. > > Also no need to rewind all the stuff later. This large step simply vanishes. > As soon as the last rebase is done, the entire task is done.
I admit that I did not follow this. So please clarify for me. With the mikado method, the rule is: If you start with the target branch able to compile (for example, it's master, or "dev", or something like that), then it will always be able to compile. When you make a change, and things break, the normal behavior is to chase down those breaks and fix them. Mikado says "First rollback, and document what you'll do later". This leaves the branch in question able to compile. The benefit of Mikado's "always rollback" approach is that you can continue making fixes/updates/improvements. And yes, this means that you are chasing a moving target -- at the same time that you are tracking down the edges that can be changed without breaking things, other things are being added to the "what needs to be updated". The closest I can decipher to a "pure git" approach is to say "I'm going to make a branch; I will change something on the branch, and it will break; instead of rolling back, I will always merge the current master/dev/whatever into my work-in-progress. This way, my cleanup work does not stop work on master, and I never diverge far from master". The downside to this approach is simple: keeping track of all the work-in-progress becomes "hard/complex" -- to keep track of it all, you have to create the same dependency graph to track everything you are doing. So the documentation step is the same in both cases, and you avoid the rollbacks by having a second active development branch with constant small merges after every update. I don't understand your "rebase" idea, and in general, I've been bitten by rebase already in toy-level projects. (So it is same to assume that while I might understand the technical aspect of moving patches from point A in the tree to point B, I don't actually understand the proper use cases of rebase.) NB: Do not assume that "you don't need to document". Large projects, multiple people, long time (enough to forget something), all add up to "Document, document, document". -- 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.
