On Mon, Mar 26, 2018 at 01:54:54AM -0700, Shirlin Joseph wrote: > I have a query. > > *Scenario:* > > Currently there are two main branches that we are utilizing A(master) and > B(branch of A). Branch is utilised for individual stories(as per delivery). > > > > When branch is utilised since the team size is huge the number of changes/ > branches created for different stories is huge and the common files changed > are many. > > > > Thus when the story for branch A is completed and merge request is raised, > since the branch is not up-to-date with the A(master). It turns out to be > mostly a manual merge. > > > > Is there a better way to handle the scenario of the branch not being > up-to-date with the master and the merge becoming a time consuming manual > merge task? > > Can we automate it?
A typical approach is to simply merge A into B from time to time, or - better - when A receives a substantial update. The resulting history won't be pretty but each merge will be simpler. A better approach is simply to have smaller tasks. That is, break down B into a series of "sub-Bs" and have each developer working on each "sub-B" to rebase their work on A before pushing each round of changes for review. (Another round can be performed right before merging into A). This way you sort of "reverse" the burden of synchronizing the lines of development into a more sensible direction - by putting them onto those who develop new stuff. You might find [1] to be enlightening on how one can really be creative with branching when it comes to implementing a development scheme when a feature can pass several "stages" of being ready for the prime time. 1. https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
