Une branche et un « lightweight tag » seront exactement équivalents. Dans les deux cas, ce sont des références nommées vers un commit. La vraie différence entre une branche et un tag, c'est que quand on fait « git checkout ; git commit », ça déplace la branche, alors que « git checkout ; git commit » va nous mettre en « detached HEAD » et ne va pas toucher au tag. Pour cette utilisation, je préfère un tag.
Tout ceci étant dit, je ne comprends pas bien pourquoi l'auteur de l'article pointé s'énerve autant pour un merge.
$ 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.
[^] # Re: git tag
Posté par Matthieu Moy (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 4.
Une branche et un « lightweight tag » seront exactement équivalents. Dans les deux cas, ce sont des références nommées vers un commit. La vraie différence entre une branche et un tag, c'est que quand on fait « git checkout ; git commit », ça déplace la branche, alors que « git checkout ; git commit » va nous mettre en « detached HEAD » et ne va pas toucher au tag. Pour cette utilisation, je préfère un tag.
Tout ceci étant dit, je ne comprends pas bien pourquoi l'auteur de l'article pointé s'énerve autant pour un 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.