pro git v2 : example fake merge

bonjour à tous,

il y a un example qui m'échappe dans la version 2 de pro git. À la page 324, dans le paragraphe juste avant la section 'subtree merging', je ne comprends pas comment les commits initiaux de 'release' peuvent être mergé ensuite dans master puisqu'il devrait être ignorés de par le fait qu'ils sont déjà dans son arborescence comme expliqué à la page 322 et que git devrait effectuer un three-way merge avec R' comme base. La représentation que je me fais de cet example est-elle correcte ?

Code:

---

1 2 3 4 5 6

F / \ M---\----M'---M" \ \ / / R---R'---R"

---

avec :

• M : master branch
• R : release branch
• F : bugfix branch

Concernant la mention de 'same branch' présent dans le paragraphe, est-ce bien 'release branch' ?

Sans plus de détail sur l'exemple proposé... difficile de te répondre ! Je n'ai pas trouvé la ref de ton exemple...

Note : tu as un forum dédié sur Développez ici

a+
Philippe

Finalement, il semblerait finalement que ma compréhension du fonctionnement de git est correcte. Le but recherché est d'intégrer le fix à la release branch et rendre les précédents commits (R) de cette branche caduc.

@Philippe : je parlais du paragraphe commençant par "This can often be useful to basically trick Git ...". J'avais pas vu le forum dédié à git. Merci de me l'avoir fait remarqué.

Je comprends mieux : dommage qu'ils n'aient pas mis un exemple avec un schéma !

Dans ce paragraphe il est question de l'option "-s ours" qui modifie la stratégie de merge... Effectivement, c'est ce que l'on appelle un fake merge : tu montes un points de merge sans merger... il faut voir le fake merge comme un point de synchro virtuel !

La méthode décrite est utile pour maintenir 2 branches qui à terme seront mergées en liant leurs évolutions au plus tôt !

Suppose que
- tu es 2 branches master et topic (supposons que ta branches topic ne doit pas être mergée rapidement)
- sur master tu fais un ou plusieurs commits que peuvent être utiles sur topic
- tu récupères les modifs de master sur topic avec un merge classique et tu règles les éventuels conflits
en plus, depuis master tu fais un fake merge (celà ne modifie pas master mais indique que tes commits sur master devront être conservés) => tu viens de réaliser un point de synchro virtuel.
- tu peut répéter l'opération
- enfin lorsque tu vas merger topic sur master tu n'auras pas à résoudre les conflits que tu déjà résolus sur ta branche topic.

Note : cette methode de points de synchro virtuels est utiles lorsque les branches master et topic sont partagées. Si ta branche topic n'est pas encore poussée sur le dépot central tu peux faire des "git rebase master" pour maintenir à jour ta branche topic et régler au plius tôt les conflits. Puis faire un merge de topic sur master lorsque c'est nécessaire.

a+
Philippe

Merci pour ces explications complémentaires. Cet exemple mériterait en effet un schéma.

Il reste toutefois encore une grande interrogation pour moi : pourquoi rendre caduc les précédents commits de topic (R) ? Est-ce un effet secondaire indésirable de la méthode ? En effet, si je ne fais erreur, si topic (R) ajoute une ligne à un endroit où master ne modifie rien, cette même ligne sera présente dans le commit résultant du premier merge (R') mais va être considérée comme supprimée lors du fake merge de topic (R') sur master et sera donc absent du merge final sur master puisque la base du merge sera R' (en faisant l'hypothèse que la ligne n'est plus remodifiée par la suite dans topic (R")). Est-ce correct ?

Je n'ai pas été clair

Code:

---

1 2 3 4

A -- M1 -- C -- m3 -- D -- M4 \ / \ / / B ------ M2 --------- E

---

Condition initiale
-1- A partir du commit initial tu créés la branche topic et tu commences à travailler avec le commit B.
-2- Tu merges topic sur master en M1 (c'est important pour la suite); et, tu travailles avec C

-3- Tu merges master sur topic avec M2
-4- Tu merges avec l'option '-s ours' topic sur master en m3
-5- Tu travailles sur master et topic avec D et
-6 -Tu merges topic sur master avec M4

En -4- tu demanges de faire un merge sans récupérer les commits de topic (fake merge)
=> B a déjà été récupéré en -2-
=> M2 sera ignoré (note si tu n'vais pas fait -2- B serait lui aussi ignoré)
En -6- tu récupères l'historique après M2 soit ici E

Ce mécanisme de double merge peut paraitre compliqué mais il a l'avantage de te permettre
- de travailler sur E avec une branche topic à jour
- de finir ton travail en M4 sans récupérer les éventuels conflits que tu as eu en M2. Bref tu traites les conflit sur ta branche de travail et au plus tot
Tu pourrais aussi avec cette procédure ne merger qu'une partie de topic sur master : par exemple ici si tu ne veux pas merger B il te suffirait se sauter -2- !

a+
Philippe

Salut Philippe,

Est-ce vraiment normal/judicieux d'intégrer la branch release non achevée dans master ? Personnellement, je comprends que la résolution des conflits se fait lors du merge de master sur release et non pas par l'inverse. Dès lors, la question que je me pose est la suivante : le fake merge sert-il vraiment à quelque chose ? En effet, en supprimant le fake merge après le merge standard de master sur release on peut backporter les bugfix ajoutés à master et gérer les éventuels conflits qui vont avec en mergeant régulièrement master sur release et finalement merger release sur master sans problème non ?

Oui sauf que rien ne te dit que tu dois repporter la totalité de release sur master (tu pourrais très bien faire une évolution spéfique à ta release).

Concernant mon exemple : les fake merges te permettent de préparer sereinement master au merge futur de topic : tu indiques en particulier que les commits de master sont les références à garder (depuis master, tu n'as pas besoin de savoir que tes merges master->topic ont provoqués des conflits sur topic) : en gros, seuls les conflits de topic->master restent visible sur master - les conflits master->topic resteront cloisonés à topic...

Encore une fois : cette technique peut être remplacée par un git rebase si tu n'a pas poussé ta branche topic sur le serveur central...

Après, il n'y a pas de solution unique. et tout dépend de ton contexte..

a+
Philippe