Re: [Hawkular-dev] Best Practices: MiQ Dependencies around other branches

I haven't found "the way" either, and the solution, if there's one, is probably tightly related to the kind of changes that are made. Maybe something that can help is in the work organization (if it's not too late for you?): trying to separate on one side all the refactoring of the existing that could be merged seamlessly without impacting existing functionalities; and on the other side, all the functional stuff, feature changes and additions. If you're able to do that then merging the refactoring part in master would help a lot: as it doesn't change the existing, it should be easier to make the merge accepted by others; and it's the part that is the most likely to generate rebase or merge conflicts, the other part shouldn't generate much conflicts if it's all about new stuff. Else, you could also have a look at "git rerere" ( https://git-scm.com/blog/2010/03/08/rerere.html or https://git-scm.com/docs/git-rerere ). I used that some years ago in such situation, it allows git to "remember" conflict resolution to avoid you having to resolve again and again the same conflicts on long lived branches. However it has its downsides, it can be error prone because sometimes the resolution you did the first time doesn't apply as well some times later. Also, squashing commits sometimes helps to reduce the repetitive rebase work. But you loose history. Hope it can help... And still looking for 'the way'! Joel On Thu, Sep 29, 2016 at 3:04 AM, mike thompson <mithomps(a)redhat.com&gt; wrote: