On Fri, Jun 23, 2017 at 8:23 AM, Pat Ferrel <p...@occamsmachete.com> wrote:
> I don’t know where to start here. Git flow does not address the merge > conflict problems you talk about. They have nothing to do with the process > and are made no easier or harder by following it. > I thought i did demonstrate that it does make conflicts much more probable per below. The point where you start your work and point where you merge it do matter. This process does increase the gap between those (which implies higher chance of conflicts and deeper divergence from the start). This is is the same reason why people try to merge most recent commit stack back as often as possible. > > >> For example: > >> Master is at A > >> Dev branch is at A - B -C ... F. > >> > >> if I start working at master (A) then i wil generate conflicts if i have > >> changed same files (lines) as in B, C, .. or F. > >> > >> If I start working at dev (F) then i will not have a chance to generate > >> conflicts with B,C,..F but only with commits that happened after i had > >> started. > >> > >> Also, if I start working at master (A) then github flow will suggest me > >> to merge into master during PR. I guarantee 100% of first time PRs will > >> trip on that in github. even if you put "start your work off dev not > >> master" 20 times into project readme. > >> > >> And then you will face the dilemma whether to ask people to resolve > merge > >> issues w.r.t. master and resubmit, which will result to high > contribtors' > >> attrition, or resolve them yourself without deep knowledge of the > author's > >> intent, which will result in delays and plain errors. > >> > >> -d > >> > > > > > >
