Hi Markus,
----- Original Message -----
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.
--
My reponse about using the Mikado method related to my initial understanding
of the problem as described, which sounded as if there were two independent
projects forked from a common base that needed "merging" back together, and
it was "too complicated", hence the option of using the mikado method for
its 'divide and conquer' approach.
However, it later emerged that a 'rebase' was what was being desired, but
one that included the merging, which unfortunately the --preserve-merges
doesn't work as hoped (see
https://public-inbox.org/git/xmqqwpa0f8zm....@gitster.mtv.corp.google.com/).
There is a video presentation about Mikado at https://vimeo.com/54450491
(leanagile scotland 2013)
Philip
--
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.
