Comment merger ?

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour !

Utilisant git et ayant souhaité me mettre aux branches, je me suis heurté à l'étape de fusion (merge). En effet, j'ai toujours des conflits et, à bien y réfléchir, ou bien je m'y prends mal, ou bien ils sont inévitables.

Par exemple, admettons que j'ai ma branche master. Je programme comme un porc donc n'ai pas documenté mon code et souhaite remédier à cela :

  • $t$ : je crée une branche docstrings à partir de master
  • $t + 1$ : je crée une branche feature-1 à partir de master pour développer une fonctionnalité
  • $t + 2$ : je crée une branche feature-2 à partir de master pour développer une autre fonctionnalité
  • $t + 3$ : dans la branche feature-1, je modifie le fichier file.py
  • $t + 4$ : dans la branche feature-2, je modifie le fichier file.py
  • $t + 5$ : dans la branche feature-1, je modifie le fichier file.py
  • $t + 6$ : je fusionne feature-1 et master
  • $t + 7$ : j'ajoute des commentaires dans le fichier file.py dans la branche docstrings
  • $t + 8$ : je fusionne feature-2 et master et obtiens des conflits, dûs aux modifications apportées à file.py via la branche feature-1
  • $t + 9$ : pareil si je fusionne docstrings et master

Et c'est dans le cas où je suis tout seul sur le projet. Comment dois-je m'y prendre ?

Merci. ^^

Edit : http://www.git-attitude.fr/2014/05/04/bien-utiliser-git-merge-et-rebase/

Édité par Vayel

+0 -0

Cette réponse a aidé l'auteur du sujet

Les conflits sont inévitables dans certains cas.

As tu regardé aussi le cherry-pick ? Et rebase ? Cela peut aider à garder une branche "propre" (linéaire). Envisage aussi de faire des update de tes branches à partir du master ou de tes autres branches.

Sinon, j'aurais envie de te dire d'éviter de trop de disperser… 3 branches pour modifier un seul fichier ? Soit tes fonctionnalités sont effectivement indépendantes et doivent être développer en parallèle, dans ce cas, je dirais qu'elle devrait être séparées dans des fichiers différents. Soit elles ne sont pas indépendant et il serait préférable de s'en occuper une par une.

Tu imagines si dans une équipe, tu donnes à 2 personnes des tâches concernant les mêmes fichiers ? Les conflits sont inévitables… (et pas forcement que dans les fichiers :) )

Édité par gbdivers

+1 -0

Cette réponse a aidé l'auteur du sujet

Ma méthode de travail lorsque je travaille sur du refactoring ou des choses non-triviales ou bloquantes:

  1. Je commite souvent, avec des messages pas forcément très explicite. Par exemple si j'ai des erreurs de compilations suite à la mise à jour d'une librarie.
  2. Lorsque c'est terminé, je rebase git rebase -i HEAD~xx
  3. Je réordonne l'ordre des commits: regroupe ceux sur la même thématique, un ordre plus cohérent
  4. Je merge un certain nombre via squash (ce qui me permet d'éditer le message du commit pour quelque chose de consistant, sinon passer par write)
  5. En cas de soucis dans l'ordre ou si j'ai mixé deux commits ou fait une erreur dans l'un des commits, je peux les séparer en autant de commit que je veux et supprimer certaines parties via edit. Lors de l'édition il faut juste reset (soft) la tête et faire autant de commits que nécessaire, puis git rebase --continue pour le valide (ou --abort). En dernier recours, cela permet également de (re)séparer des commits que l'on a squashé trop tôt ou d'une mauvaise manière.

En règle générale, réordonner + squash permet d'éditer correctement les messages et de retrouver un historique propre et sans conflit. Les conflits interviennent si tu mélanges deux taches au sein d'un même commit, auquel cas edit permet de sauver la donne (même si une branche aurait été préférable dès le début).

Édité par KFC

+1 -0
Auteur du sujet

Merci à vous deux !

  • Une petite question

Puis-je créer localement une branche à partir d'une distante ? Typiquement, je crée une branche br au lycée, pousse ça sur GitHub puis, de retour chez moi, souhaite reprendre mon travail sur br. La procédure suivante est-elle convenable :

1
2
3
git pull origin master
git checkout -b br
git pull origin br
  • Et un problème

Je souhaite contribuer au dépôt A. J'en fais donc un fork. Admettons alors qu'il ait besoin d'ajout de docstrings (Python). Je crée une branche docstrings sur laquelle je vais faire mon travail. De plus, je crée également une branche unittests pour écrire une série de tests unitaires.

Je termine mon travail sur la branche unittests et effectue une pull request vers A. Elle est acceptée. Comment faire pour me mettre à jour sur ma branche master et dosctrings ?

La question est bien sûr identique si A est modifié par un autre contributeur.

Un cas concret ici.

Merci !

Édité par Vayel

+0 -0

Pour ta premiere question c'est presque OK :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# On recupere master
git pull origin master
# On cree la branche br (pas terrible comme nom)
# Elle est cree au niveau de HEAD de master
git checkout -b br
# [bricole, add, commit toussa...]
# [...]
# On envoie br à origin, pour qu'elle soit sur le serveur
# git push origin master
# on rentre a la maison
# On recupere br a la maison
git pull origin br

Pour la deuxieme question : Oui c'est possible.

Une fois que la branche unittest est accepté, elle sera mergée dans la branche principale (disons master) du depot upstream. Il te "suffira" alors de mettre a jour soir le depot en entier de upstream soit juste cette branche upstream/master pour avoir en local la copie à jour.

Ensuite, dans ta branche docstrings tu feras un rebase de upstream/master pour y amener les mises à jour.

(les noms en italique ne sont que des conventions, pas des obligations)

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+0 -0
Auteur du sujet

A la ligne 9, ça ne serait pas plutôt git push origin br ?

Un git pull origin br ne va-t-il pas mettre à jour la branche courante plutôt que d'en créer une ?

Pour la deuxième question, pourrais-tu détailler les commandes ? Aurais-je un truc comme ça :

1
2
3
4
5
6
git push origin unittests
# PR vers upstream/master
# PR acceptée
git checkout master
git pull upstream master
# Puis un rebase dans la branche docstrings

En faisant ça, j'aurais toujours le commit Merge from Vayel/..., non ? Du moins dans ma branche master.

+0 -0

Cette réponse a aidé l'auteur du sujet

Il te faut utiliser un pull avec rebase juste avant de pusher. De cette manière, tu récupères les modifications déjà faites par tes collègues et pushés, et les tiennent vont venir s'inscrire par dessus. L'historique sera linéaire même si les dates peuvent s'intercaller (c'est la date du push qui va compter et non celle du commit).

git pull --rebase git push origin master

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte