J'essaie de prendre une branche avec des changements et de la ramener à l'identique de l'amont dont elle a divergé. Les changements sont à la fois locaux et ont été poussés sur github, donc ni l'un ni l'autre ne peut être modifié. git reset
o git rebase
sont vraiment viables, puisqu'ils modifient l'historique, ce qui est une mauvaise chose avec une branche qui a déjà été poussée.
J'ai aussi essayé git merge
avec diverses stratégies mais aucune d'entre elles n'annule les changements locaux, c'est-à-dire que si j'avais ajouté un fichier, une fusion pourrait remettre d'autres fichiers en ligne, mais j'aurais toujours ce fichier que l'amont n'a pas.
Je pourrais simplement créer une nouvelle branche à partir de l'amont, mais j'aimerais vraiment une fusion qui, en termes d'historique de révision, applique toutes les modifications pour prendre ma branche et la rendre à nouveau identique à l'amont, de sorte que je puisse pousser cette modification en toute sécurité sans altérer l'historique. Existe-t-il une telle commande ou série de commandes ?
12 votes
Si vous ne vous souciez pas de préserver les changements, pourquoi ne pas simplement supprimer et recréer la branche ? "L'histoire du projet" n'a pas besoin d'être sacrée. Git est un outil pour aider les développeurs à communiquer. Si ces changements n'aident pas à cela, jetez-les.
0 votes
+100 @wnoise - surtout si les changements ont déjà été fusionnés.
13 votes
Je tiens à préserver l'histoire à la fois parce qu'elle est publiée à des fins de collaboration et parce que je pourrais avoir envie d'y revenir. Pourquoi s'embêter à utiliser le contrôle de révision si vous ne gardez que la dernière version ?
1 votes
C'est un argument subjectif, mais pour moi, le but d'un VCS n'est pas d'enregistrer chaque détail de l'histoire du projet, mais seulement d'enregistrer les changements du contenu (commits), de vous permettre de manipuler l'arbre/historique basé sur ces commits (branching, merging, rebasing, resetting, etc), et de vous permettre de visualiser des rapports basés sur l'histoire (diffs, logs, blame, etc). git est le "stupide traqueur de contenu" - je le vois comme un outil pour gérer le code source, pas une machine à remonter le temps.
9 votes
Comme vous l'avez dit, c'est subjectif. Ce qui m'importe, c'est de pouvoir examiner les approches abandonnées et de voir quelles décisions ont été prises à un moment donné dans le passé. Et je tiens à ce que ma décision d'abandonner quelque chose ne détruise pas les points de convergence que d'autres pourraient pointer du doigt.