should read And then you will face the dilemma whether to ask people to resolve merge issues w.r.t. *dev* and resubmit against *dev*, 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.
On Thu, Jun 22, 2017 at 2:48 PM, Dmitriy Lyubimov <dlie...@gmail.com> wrote: > > > On Wed, Jun 21, 2017 at 3:00 PM, Pat Ferrel <p...@occamsmachete.com> wrote: > >> Which is an option part of git flow but maybe take a look at a better >> explanation than mine: http://nvie.com/posts/a-succes >> sful-git-branching-model/ <http://nvie.com/posts/a-succe >> ssful-git-branching-model/> >> >> I still don’t see how this complicates resolving conflicts. It just >> removes the resolution from being a blocker. If some conflict is pushed to >> master the project is dead until it is resolved (how often have we seen >> this?) > > > This is completely detached from github reality. > > In this model, all contributors work actually on the same branch. In > github, every contributor will fork off their own dev branch. > > In this model, people start with a fork off the dev branch and push to dev > branch. In github, a contributor will fork off the master branch and will > PR against master branch. This is default behavior and my gut feeling no > amount of forewarning is going to change that w.r.t. contributors. And if > one starts off his/her work with the branch with intent to commit to > another, then conflict is guaranteed every time he or she changes the file > that has been changed on the branch to be merged to. > > 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 >
