Merging a grand children branch in GIT

Question

I'm in a specific situation and I'd like an opinion before messing up all my branches :-) Currently, I have this architecture :

master
   hotfix
   development
      p2

Recently, I had an issue and had to work on the hotfix branch. Now it's fixed and I merged it to the master one. Usually, when I deploy something, it's from the development branch, however, due to dramatic schedule modifications, I will have to deploy the p2 branch instead of the development one. Indeed, the changes in p2 must go live before the one in development (and the one in development can't go before the ones in p2).

Deploying p2 is not an issue, but then I have questions about the next steps.

1. Is it possible to merge the master branch with the p2 branch (in order to have the latest changes) without merging into development first?
2. If 1 is possible, I'd like to merge p2 back into master once the code is deployed, but then, if I try to merge master into development (to put the changes of p2 in development), will all the changes I made in p2 be included in the merge ? I'm afraid that it won't be the case because of the first merge I did with master (as its latest commit has been done way after all the changes in p2).

Thanks

Answer 1

Somewhat more detailed answer :

Your starting state is :

# sketch 1 :

*--A--*--*--*--*--*--*--*--* master
    \  \            /
     \   *--*--*--* hotfix
      \
       \
        *--*--B--*--*--* development
               \
                 *--*--*--* p2

You can merge p2 into master :

# sketch 2 :

*--A--*--*--*--*--*--*--*--*-----* master
    \  \            /           /
     \   *--*--*--* h          /
      \                       /
       \                     /
        *--*--B--*--*--* d  /
               \           /
                 *--*--*--* p2

Once you have done this, git has stored the fact that the B commit (and all of the commits between A..B) is part of master's history.

So later on, when you decide to merge development into master :

# sketch 3 :

*--A--*--*--*--*--*--*--*--*-----*-----* master
    \  \            /           .     /
     \   *--*--*--* h          .     /
      \                       .     /
       \                     .     /
        *--*--B--*--*--*--*----*--* development
               \           .
                 *--*--*--* p2

it will only look at the differences between B..development (instead of A..development)

---

On these sketches, p2 is drawn below development.

But git does not care about this notion of "below".

From git's point of view, sketch 2 is the same as :

# sketch 2':

         *--*--*--*  h
       /            \
*--A--*--*--*--*--*--*--*--*--* master
    \                        /
     \            *--*--*--* p2
      \         /
       \       /
        *--*--B--*--*--* d

And sketch 3' may be clearer in showing how git resolves the new "forking point" between master and development :

# sketch 3':

         *--*--*--*  h
       /            \
*--A--*--*--*--*--*--*--*--*--*------* master
    \                        /      /
     \            *--*--*--*       /
      \         /                 /
       \       /                 /
        *--*--B--*--*--*--*--*--* development