Discussion :

[Gébix]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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' ?

[Philippe Bastiani]

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

[Gébix]

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é.

[Philippe Bastiani]

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

[Gébix]

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 ?

[Philippe Bastiani]

Je n'ai pas été clair

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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