Je ne peux pas vraiment penser à un moment où j'utiliserais git merge plutôt que git rebase et pas je veux qu'un commit apparaisse. Y a-t-il un moyen de configurer git pour que l'avance rapide soit désactivée par défaut ? Le fait qu'il y ait un --ff semble impliquer qu'il existe un moyen, mais je ne le trouve pas dans la documentation.
Il semble qu'il y ait encore une question en suspens dans le fil de discussion : Comment le faire globalement (c'est-à-dire pour toutes les branches) ? Pour les enregistrements, nous pouvons utiliser ce qui suit :
git config --add merge.ff false...pour qu'elle s'applique à toutes les branches du référentiel actuel. Pour qu'elle s'applique à toutes les branches du tous les référentiels où quelqu'un a pas l'exécuter sans le --global (les paramètres locaux prévalent sur les paramètres globaux), exécutez ceci :
git config --global --add merge.ff falseDe la documentation :
merge.ff
Par défaut, git ne crée pas de commit de fusion supplémentaire lorsqu'il fusionne un commit qui est un descendant du commit courant. Au lieu de cela, l'extrémité de la branche courante est accélérée. Lorsqu'elle prend la valeur false, cette variable indique à git de créer un commit de fusion supplémentaire dans ce cas (ce qui équivaut à donner à la variable--no-ffde la ligne de commande). Lorsqu'elle est définie à seulement, seules ces fusions rapides sont autorisées (ce qui équivaut à donner à l'option--ff-onlyde la ligne de commande).
Note : merge.ff a été introduit dans Git 1.7.6. Elle n'est pas effective dans les versions antérieures.
Oui, il y a --no-ff . Vous pouvez configurer les options de fusion par branche, par ex.
git config branch.master.mergeoptions "--no-ff"ajoute les éléments suivants à votre $(REPO)/.git/config fichier :
[branch "master"]
mergeoptions = --no-ffNote de bas de page : en parlant de mon expérience, j'ai finalement trouvé que la désactivation de l'avance rapide était surtout utile pour les nouveaux venus dans git - cependant, une fois que l'on commence à sentir les flux de travail et les concepts, il faut absolument éviter de brouiller le graphique du journal avec des tonnes de commits inutiles du type 'merged remote ..blarf'.
Note de bas de page 2, une décennie plus tard : les autres réponses ci-dessous fournissent des options de configuration plus modernes, mais vraiment, vous voulez probablement VRAIMENT rester avec les valeurs par défaut (c.-à-d. avancer rapidement quand c'est possible) à notre époque, parce que les merge-commits vides ne font que rendre l'historique beaucoup plus difficile à comprendre.
Apprendre git, c'est un peu comme faire de l'alpinisme ; mais au lieu de commencer par de petites falaises et de progresser vers des plus difficiles, git vous fait escalader la même montagne encore et encore, pour tomber à des hauteurs différentes à chaque fois, chaque fois tout aussi surpris que la bouée de sauvetage ne soit pas attachée.
En lisant le fil des réponses, j'ai fini par utiliser les deux options suivantes
git config --global pull.ff only # Disallows non ff merges on pull. Overrides merge.ff when pulling
git config --global merge.ff false # even create extra merge commit when fast forward merge would be possibleJ'ai également constaté que ce réglage évite les problèmes lors du tirage.
git config --global pull.rebase true # set up pull to rebase instead of merge
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
3 votes
J'utilise
mergetout le temps pour les branches qui n'ont pas fait de commits depuis leur télécommande afin de les faire avancer rapidement. Cela semble être la façon la plus simple et la plus sûre de le faire. Je suis curieux, vous avez évidemment un cas d'utilisation. Pourquoi voudriez-vous créer un commit de fusion lorsqu'il n'y a pas de commits d'un côté de la branche ?12 votes
J'utilise les branches pour créer un regroupement logique de commits. Ainsi, si je fais une fusion, c'est essentiellement un moyen de dire "ces commits vont ensemble". On peut presque y penser comme à un pauvre homme interactif rebase et squash :-)
14 votes
La désactivation de l'avance rapide est extrêmement utile, en particulier lorsque vous suivez un modèle tel que Un modèle de branchement Git réussi
2 votes
Veuillez remplacer la réponse acceptée par la réponse d'Eric Platon. stackoverflow.com/a/6810687/3408 - J'ai suivi les étapes de la réponse acceptée, puis je me suis rendu compte que cela ne concernait que la branche principale du dépôt actuel, ce qui est stupide.
0 votes
@Steiny Non, ça ne fait que mettre le désordre dans votre référentiel : endoflineblog.com/gitflow-considered-harmful .
5 votes
@jpmc26 Chacun son truc je suppose. Il se trouve que je ne suis pas d'accord avec cet article. Trouver les deux parents d'un commit de fusion n'est pas difficile et vous indique exactement quels étaient les changements. Ensuite, vous pouvez prendre ces changements et faire un "rebase sur" une autre branche. Avec le modèle plat, vous devez trouver et sélectionner manuellement les modifications. Nous avons choisi d'adopter le branchement. Bien sûr, c'est complexe lorsqu'on regarde l'arbre entier, mais c'est la réalité, de multiples changements se produisant en parallèle. Tout aplatir ne fait que masquer ce qui s'est réellement passé.
0 votes
@Steiny Oui, ça cache "ce qui s'est vraiment passé". Et c'est une bonne chose. Il supprime les détails non pertinents dont personne n'a besoin de se soucier et préserve ceux qui sont importants ; c'est ce que fait une bonne documentation. Trouver le parent d'une fusion unique n'est pas difficile, c'est vrai. Retracer 100 commits sur 4 branches avec beaucoup de croisements pour essayer de comprendre ce qui a réellement changé et où, ne semble pas particulièrement facile, surtout quand ces commits peuvent ou non introduire des changements dans le code de base. (C'est ce que recommande/exige Gitflow).
3 votes
@jpmc26 Vous faites des affirmations très fortes et partiales, vous avez littéralement dit "Non, ça fait juste un gâchis de votre référentiel" concernant cet article. nvie.com/posts/a-successful-git-branching-model Bien que ce flux de travail Git puisse ne pas vous convenir, il fonctionne pour certaines équipes d'entreprise.
0 votes
Je comprends que git config modifie les paramètres par utilisateur. Existe-t-il un moyen de désactiver l'avance rapide pour le dépôt (pour tous les utilisateurs), créant ainsi une sorte de "politique de fusion du dépôt" ?