Comment écraser le contenu d'une branche avec celui d'une autre?

Bonjour tout le monde !

J’ai une interrogation à vous soumettre sur des manipulations avec git aujourd’hui.

J’ai une branche sur laquelle j’avais préparé une fonctionnalité. Suite à un changement de priorités, cette branche n’a pas été maintenue à jour régulièrement, et la PR n’a bougé que dernièrement pour être rejetée en l’état, les spécifications n’étaient pas complètes alors (!).

Le hic, c’est que le changement de priorités a évidemment fait évoluer la branche master, à tel point qu’il y a un très grand nombre de conflits pour ces deux branches désormais, et ce pour des modifications plutôt mineures au départ, mais qui sont caduques avec l’évolution principale.

Du coup, j’aurais souhaité pouvoir "écraser" le contenu de la branche avec celui de master. Seulement, j’aimerais pouvoir mettre à jour uniquement le code de ma branche afin de pouvoir repartir depuis master. rebase et reset ne me permettent pas de pousser le nouvel état du code, parce que j’ai déjà quelques commits de poussés sur la branche, donc les changements ne sont plus "fast-forward" (pour reset, c’est le même souci que ce soit soft, mixed ou hard).

Est-ce qu’il y a une méthode autre que supprimer/recréer la branche afin de repartir depuis une version master "propre" ?

Merci d’avance 

Salut,

git checkout branch
git reset --hard master

Après si tu souhaites quand même récupérer tes commits, tu peux essayer de faire un git rebase --onto (le manuel explique bien comment il fonctionne, avec des dessins).

Pour ce genre de rebase fastidieux, je te conseille d’activer rerere (git config --global rerere.enabled true) qui te permettra de le faire en plusieurs fois, ou de d’économiser du temps si tu as plusieurs branches à rebaser.

Salut !

Si j’ai bien compris, tu voudrais rebaser ta branche sur master en ignorant les conflits et en privilégiant les modifications côté master ? Si oui, tu peux jeter un coup d’oeil du côté des paramètres -Xtheirs et -Xours, qui permettent de privilégier une version (la leur ou la nôtre) plutôt que de marquer les différences comme des conflits de fusion.

À noter que c’est relativement dangereux si tu n’as pas prévu de tout squasher pour tester le commit en question et que tu n’as pas de tests automatique, puisque tu ne sais pas ce qui va introduire une régression ou pas.

Ah en effet, tu as raison. Je mentionnais ça juste parce que ça m’avait bien aidé dans un cas particulier (où j’avais des tests unitaires). Ton approche est en effet bien meilleure.

Merci pour vos réponses.

Je n’ai rien qui risque de sauter, et les commits précédemment pushés ne me servent plus à rien. J’avais justement déjà tenté un reset --hard, mais le résultat semble être le même que si j’avais fait un rebase (cf. mon explication dans le premier message).
De ce que je comprends de git, je souhaite ne pas modifier l’index, et probablement pas HEAD non-plus¹, comme si le code actuel de master (modulo les quelques changements que je souhaiterais faire à partir de celui-ci) était le fruit d’un nouveau travail à pousser tel-quel dans la branche, en fait.

Après avoir fait ça, il est possible de cleaner le repo pour supprimer les commits déréférencés

git reflog expire --expire-unreachable=now --all
git gc --prune=now

Ça me parait étrange de vouloir se tirer une balle dans le pieds comme ça.

Si tu as commit un truc immense par erreur et que tu es sur de vouloir clean t’es objets et tous tes trucs dereferences..