Comments on: Une astuce pour ne plus avoir peur des merges avec Git http://sametmax.com/une-astuce-pour-ne-plus-avoir-peur-des-merges-avec-git/ Du code, du cul Mon, 28 Oct 2019 11:54:55 +0000 hourly 1 https://wordpress.org/?v=4.9.7 By: Matthieu Moy http://sametmax.com/une-astuce-pour-ne-plus-avoir-peur-des-merges-avec-git/#comment-1038 Fri, 03 Aug 2012 19:01:35 +0000 http://sametmax.com/?p=1147#comment-1038 Non, le git stash n’est pas nécessaire, ou en tous cas n’apporte pas de sécurité avant de faire un merge.

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.

]]>
By: Sam http://sametmax.com/une-astuce-pour-ne-plus-avoir-peur-des-merges-avec-git/#comment-974 Thu, 02 Aug 2012 00:09:52 +0000 http://sametmax.com/?p=1147#comment-974 Git stash est indispensable si on veut faire un pull qui contient des fichiers modifiés.

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.

]]>
By: Matthieu Moy http://sametmax.com/une-astuce-pour-ne-plus-avoir-peur-des-merges-avec-git/#comment-959 Tue, 31 Jul 2012 20:28:33 +0000 http://sametmax.com/?p=1147#comment-959 Si c’est juste pour pouvoir annuler un merge en cours, pas besoin de tout ça :


$ 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 ?)

]]>
By: Sam http://sametmax.com/une-astuce-pour-ne-plus-avoir-peur-des-merges-avec-git/#comment-693 Wed, 18 Jul 2012 04:39:23 +0000 http://sametmax.com/?p=1147#comment-693 Je comprendrais très bien qu’on utilise un tag. Un tag point de sauvegarde a parfaitement du sens pour moi.

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

]]>
By: Mes trouvailles du jour : 17 July 2012 | DotMana http://sametmax.com/une-astuce-pour-ne-plus-avoir-peur-des-merges-avec-git/#comment-690 Wed, 18 Jul 2012 00:44:11 +0000 http://sametmax.com/?p=1147#comment-690 […] Une astuce pour ne plus avoir peur des merges avec Git | Sam & Max: Python, Django, Git et du cu… Quelques rappels utiles sur le merge sous Git et comment revenir à un commit précédent. […]

]]>
By: Nicolas http://sametmax.com/une-astuce-pour-ne-plus-avoir-peur-des-merges-avec-git/#comment-676 Tue, 17 Jul 2012 14:05:12 +0000 http://sametmax.com/?p=1147#comment-676 Oui mais une branche, à mon sens, c’est fait pour vivre (un minimum), je trouve donc personnellement le tag plus approprié (est-ce que l’abondance de tags peut nuire à un repo git ? vous avez 2 heures) :)

]]>
By: Sam http://sametmax.com/une-astuce-pour-ne-plus-avoir-peur-des-merges-avec-git/#comment-675 Tue, 17 Jul 2012 14:01:54 +0000 http://sametmax.com/?p=1147#comment-675 Ca marche exactement pareil avec un tag. Mais les tags ne sont sémantiquement fait pour être supprimés. Une branche, c’est sémantiquement jetable. En revanche techniquement, les deux sont des étiquettes, et les deux peuvent être créés, supprimés, et checkouté de la même manière.

]]>
By: Nicolas http://sametmax.com/une-astuce-pour-ne-plus-avoir-peur-des-merges-avec-git/#comment-674 Tue, 17 Jul 2012 13:25:57 +0000 http://sametmax.com/?p=1147#comment-674 Merci pour ces différents rappels !

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

]]>