Guys, as you know, my ability to contribute is very limited lately, so i don't feel like my opinion is worth as much as that of a regular committer or contributor. In the end people who contribute things should decide what works for them.
I just put forward a warning that while normally this workflow would not be a problem IF people are aware of the flow and start their work off the dev branch, based on my git/github experience, a newbie WILL fork from master to a private PR branch of her/his own to commence contribution work. Which, according to proposed scheme, WILL be quite behind the dev branch that she will then be asked to merge to. Which WILL catch the unsuspecting contributor unawares. They will find they'd have a significant divergence to overcome in order to attain the mergeability of their work. On Thu, Jul 20, 2017 at 9:06 AM, Dmitriy Lyubimov <dlie...@gmail.com> wrote: > > > 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 >> >> >> > >> > >> >> >
