Git accepte de démarrer le merge seulement si les fichiers contenant des modifs non-commitées ne sont pas ceux concernés par le merge. L’option que tu cherches dans Git qui empêche de démarrer un merge en cas de danger existe déjà, elle est là par défaut et depuis toujours.

Ce que tu as raté, c’est l’option –merge de git reset (qui elle, n’existe pas depuis toujours). Conseiller “git reset –hard” à un débutant, par contre, je ne trouve pas que ce soit un bon conseil. C’est vraiment très, très rare que “git reset –hard” soit la bonne réponse à une question depuis qu’on a “reset –keep” et “reset –merge”.

“git stash” est nécessaire si les fichiers concernés par le merge sont modifiés localement, mais à ce moment là, Git aurait refusé de démarrer le merge de toutes façons (en suggérant “git stash”).

Pour les tags, je sais bien comment il marchent, mais je ne vois pas pourquoi un tag serait fait pour exister plus longtemps qu’une branche. Ce qui distingue la durée de vie, c’est plutôt le fait de faire un push ou pas dessus (i.e. garder privé les trucs qui n’intéressent pas les autres). Avec une branche, “git checkout ; git commit” va déplacer la branche, ce qui a peu de chances d’être ce que tu veux. Un tag est fait pour ne pas bouger (c’est ça la seule différence techniquement entre un lightweight tag et une branche avec Git: “git checkout ” te mets en detached HEAD), et c’est vraiment ce que tu veux ici.

Pour le tag, le principe sémantique est de dire “ceci est important dans mon historique”. Généralement c’est fait pour rester. Par contre dans git, les branches, contrairement à SVN, sont faites pour être très temporaires (même si on en garde certaines très longtemps pour le dev et le trunk) du fait des workflow à base de fork/commit/rebase.

Techniquement on peut utiliser un tag ou une branche, ça n’a pas vraiment d’importance. C’est juste que si tu quittes précipitement ton bureau, il y a plus de chance que tu vois ta banche “backup” à ton retour et que ça te revienne, qu’un tag (lister les tags, ça se fait une fois par mois à tout pêter).

Notez bien que ce sont des techniques pour débutants: le but est de les rassurer en leur donnant un choix facile, comprehensible, avec des éléments par défaut sains. Ce ne sont pas les plus rapides, et il y a des décisions arbitraires.


$ git pull
# ...
# ratage de résolution de conflits
# ...
$ git reset --merge


git refuse de démarrer un merge si les fichiers concernés par le merge sont modifiés, et « git reset --merge » ne va réinitialiser que les fichiers concernés par le merge, donc ça marche, sans point de sauvegarde (c’est juste HEAD), et sans « git stash » préalable.

(sinon, j’ai pas compris en quoi les tags ne seraient pas faits sémantiquement pour être supprimés, un « lightweight tag », c’est justement bien à ça que ça sert, non ?)

Par contre je ne dirais pas qu’une branche doit vivre une minimum. Je vais parfois des branches pour quelques minutes seulement.

Pourquoi est-ce qu’un tag ne serait pas suffisant, si c’est juste pour nommer explicitement un commit ?