0
votes

Git - comment courber de manière récurrente fusionnement à une branche principale

J'ai deux branches:

  1. une branche personnelle que je m'engage à plusieurs fois par jour.
  2. une branche "dev", que je veux parfois fusionner ma branche personnelle change, mais avec des messages de validation écrasés.

    Après la fusion, je veux continuer à utiliser ma même branche personnelle, puis être capable de revenir à la branche de développement à volonté.

    avec SVN, c'est assez facile à faire sans jamais obtenir de conflits de fusion.

    1. commit plusieurs changements sur la branche personnelle
    2. Fusionner des modifications à la branche DEV, qui enregistrera un seul message de validation
    3. Fusionner le changement de l'étape 2 retour à la succursale personnelle, mais "uniquement des informations d'enregistrement de fusion" afin qu'il ne fusionne aucun contenu.
    4. Répétez l'étape 1.

      Maintenant, par Dev Direction, sait ce qu'il a depuis la succursale personnelle, et ma branche personnelle sait qu'il a tout de la branche principale.

      avec git, j'ai essayé d'utiliser git fusion --squash pour aller de la succursale personnelle à destination de Dev Direction, ce qui a été excellent la première fois. Mais la deuxième fois, je reçois un tas de conflits. Depuis le fusionné --squash ne fusionne pas les engagements originaux, mais fait une nouvelle commission qui n'est pas liée aux engagements originaux, Git ne réalise pas que j'ai déjà fusionné de contenu de contenu de ma branche personnelle à la branche de dev.

      Y a-t-il une solution à ce flux de travail dans Git? Il semble que je fusion --squash une succursale, je dois faire une nouvelle branche pour la prochaine fois.


0 commentaires

3 Réponses :


2
votes

Voulez-vous que les révisions écrasées soient sur le côté de Dev? Comme, une révision d'une courge après l'autre? Si tel est le cas, vous pourriez faire:

git checkout --detach my-branch
git reset --soft the-previous-squash-commit
git commit -m "A new squash operation that covers revisions x, y and z"
git checkout dev
git merge -m "Merging a new squash commit" HEAD@{1} # given that I didn't have a branch set up for the squashed revision


2 commentaires

Ok, merci, je peux voir comment cela me permettrait d'apporter plus de modifications à la branche de développement. Mais qu'en est-il d'apporter des changements de la succursale de développement à ma branche personnelle?


En fait, on dirait que cela aura toujours des conflits. Actuellement, j'ai fusionné un ensemble de modifications apportées à la succursale de Dev à l'aide d'une commission écrasée. Mais j'essaie de fusionner / de rétrécir un autre ensemble de modifications de la succursale DEV, mais la succursale DEV ne sait pas qu'il a obtenu le premier ensemble de changements écrasés de ma branche. Je ne peux pas comprendre cela.



1
votes

La première chose à comprendre est que la façon dont vous décrivez le comportement souhaité (fusionner à l'enregistrement ciblé que 1 commit) est exactement à quel point la défaillance de la défaillance ne fonctionne pas.

La raison pour laquelle il peut sembler autrement, c'est que de nombreuses commandes GIT, par Par défaut, suivez toutes les branches qui se nourrissent d'une fusion. Vous pouvez modifier cela en donnant l'option - première parente à la commande xxx

à la fois des fonts réguliers et "squash fusionne" enregistrement exactement un nouveau Commettez-la et placez-le sur la branche cible (c.-à-d. La branche vérifiée lorsque vous émettez la commande).

La différence est que la courge fusionne de prétendre qu'ils n'écrivent pas une fusion - c'est-à-dire que le parent seul du nouveau commit est la pointe antérieure de la branche cible. Une fusion normale a un 2e parent - quelle que soit la branche que vous fusionnez - et comme vous l'avez remarquée, c'est nécessaire si vous souhaitez qu'une fusion ultérieure fonctionne correctement.

Vous pouvez sauter à travers des cerceaux pour réinventer la roue . Par exemple, EFTSHIFT0 vous a donné un moyen de faire, à tout moment, de faire dev correspond à la pointe de votre autre branche - qui est un peu comme la fusion, quelle que soit la base de fusion, tant qu'il n'y a nulle part que votre branche Cela contribue jamais à dev . Et si vous recherchez afin que vous puissiez même trouver des solutions générales plus générales.

Mais ce que toutes ces solutions ont en commun, ils travaillent contre le grain de la manière dont Git est censé travailler. Il est vraiment beaucoup plus facile d'utiliser Git comme prévu - c'est-à-dire simplement fusionner votre succursale dans Dev lorsque vous souhaitez porter ces modifications, et si vous souhaitez une sortie qui ne suive pas l'utilisation de la branche latérale premier parent .


0 commentaires

1
votes

Après un git fusion --squash code>, une branche ne doit pas être utilisée pour une fusion ultérieure.

Si vous insistez sur l'utilisation d'une fusion de squash, vous pouvez utiliser ce flux: P>

git checkout dev
git merge --squash personal
git tag personal_1_0 personal  #optional to save old personal branch
git checkout -B personal


0 commentaires