/ / Comment changer la branche git à partir de laquelle j'ai ramifié? - git, contrôle de version, github, création de branches et fusion

Comment changer la branche git à partir de laquelle je suis ramifié? - git, version-control, github, branching-and-merging

Je travaillais sur une branche et j'ai fait un git checkout -b feature/other-feature, a effectué des travaux, les a validés puis les a poussés vers la fonctionnalité d'origine / une autre fonctionnalité sur github.

Lorsque j'ai créé une demande d'extraction à partir duother-feature branch sur github Je me suis rendu compte qu’il affichait une charge de commits provenant de la branche de fonctionnalité originale - des commits qui devaient à juste titre être fusionnés pour se développer depuis la branche originale.

Je pense que ce que j'ai fait de mal, c'est d'omettre git checkout develop avant moi git checkout -b feature/other-feature et donc ce que je pense que je veux faire pour corriger cette situation est de rebaser l’autre caractéristique sur le développement.

Mais étant donné que j’ai poussé mon erreur vers l’origine et que d’autres personnes ont des clones de ce dépôt, dois-je procéder à une refonte ou faire autre chose?

Réponses:

3 pour la réponse № 1

Oui, vous devez rebaser votre copie de feature/other-feature. Cependant, dans ce cas, un simple git rebase develop ne fonctionnera probablement pas, parce que vous avez dérivé d'une autre branche de fonctionnalité, au lieu de directement hors develop. Vous devez utiliser rebase --onto:

git rebase --onto develop feature/earlier-feature feature/other-feature

Ici, feature/earlier-feature est la branche de fonctionnalité que vous avez vérifiée lorsque vous mourez de l'original git checkout -b feature/other-feature.

Ce rebase:

  1. Prenez les engagements feature/other-feature qui sont ne pas dans feature/earlier-feature.
  2. Réappliquez ces engagements à develop.

Vous devriez vous retrouver avec une branche modifiée feature/other-feature qui est maintenant basé sur develop.


Remarques

  • En raison du rebasage, vous devrez forcer votre branche vers votre référentiel GitHub. Ce n'est pas un problème, tant que vous avez le seul clone de votre référentiel. Si vous utilisez le dépôt avec d'autres, les choses sont plus difficiles (voir ci-dessous).
  • Le rebase peut provoquer des conflits. Vous devrez les résoudre manuellement.
  • Lectures complémentaires: Les concepts derrière le rebasage et la signification de rebase --onto sont bien expliqués dans le livre "Pro Git". Voir chapitre 3.6, Git Branching - Rebasing.

Si d'autres ont cloné votre référentiel

vous écrivez

Mais étant donné que j'ai poussé mon erreur à l'origine et que d'autres personnes ont clones de ce dépôt, dois-je rebaser ou faire autre chose?

Vous pouvez toujours rebaser comme décrit ci-dessus. Cependant, vous ne devez pas forcer la branche rebasée sous l'ancien nom. À la place, créez une copie de la branche:

git checkout -b feature/other-feature-2 feature/other-feature

Cela va créer une nouvelle branche feature/other-feature-2 c'est une copie exacte de feature/other-feature. Vous pouvez ensuite rebaser la nouvelle branche et la pousser sous le nouveau nom. Dites ensuite à tout le monde que feature/other-feature a été remplacé par feature/other-feature-2et supprimer feature/other-feature sur GitHub. Avoir à dire à tout le monde est le prix à payer pour le rebasage :-).