Après un git pull origin master j'obtiens le message suivant:
warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull: git config pull.rebase false # merge (the default strategy) git config pull.rebase true # rebase git config pull.ff only # fast-forward only You can replace "git config" with "git config --global" to set a default preference for all repositories. You can also pass --rebase, --no-rebase, or --ff-only on the command line to override the configured default per invocation. remote: Enumerating objects: 4, done. remote: Counting objects: 100% (4/4), done. remote: Compressing objects: 100% (4/4), done. remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (4/4), 51.49 KiB | 850.00 KiB/s, done.
Ensuite, le tirage a été effectué avec succès. Mais encore, j'ai des doutes sur ce message.
Quelle est la meilleure chose à faire dans ce cas?
4 Réponses :
git config pull.ff only ou de manière équivalente git pull --ff-only est le plus sûr. La raison en est qu'un rebase peut écraser l'historique et peut entraîner la perte de validations si un autre développeur a forcé la même branche.
Mais tous sont valables.
Dans son mode par défaut, git pull est un raccourci pour git fetch suivi de git merge FETCH_HEAD.
Lorsque vous effectuez un
git pull origin master,
git pulleffectue une fusion, ce qui crée souvent un commit de fusion. Par conséquent, par défaut, extraire de la télécommande n'est PAS une opération inoffensive: cela peut créer un nouveau commit sha qui n'existait pas auparavant. Ce comportement peut semer la confusion chez un utilisateur, car ce qui semble être une opération de téléchargement inoffensive modifie en fait l'historique des validations de manière imprévisible.Pour éviter cela, vous devez
git config pull.ff only(ou pas? lisez la suite pour voir lequel correspond à vos besoins)
Avec
git pull --ff-only, Git ne mettra à jour votre branche que si elle peut être «transférée rapidement» sans créer de nouveaux commits. Si cela ne peut pas être fait,git pull --ff-onlysimplement avec un message d'erreur.Vous pouvez configurer votre client Git pour qu'il utilise toujours
--ff-onlypar défaut, donc vous obtenez ce comportement même si vous oubliez l'indicateur de ligne de commande:git config pull.ff falseRemarque: l'indicateur
--globalapplique la modification à tous les référentiels de votre machine. Si vous souhaitez ce comportement uniquement pour le référentiel dans lequel vous vous trouvez, omettez l'indicateur.Pris d' ici
Cet avertissement a été ajouté dans Git 2.27, comme l'a souligné Joe dans sa réponse.
Voici à quoi ressemble l'avertissement complet:
Tirer sans préciser comment concilier des branches divergentes est déconseillé. Vous pouvez supprimer ce message en exécutant l'une des commandes suivantes avant votre prochaine extraction:
git config pull.rebase false   # merge (la stratégie par défaut)
git config pull.rebase true    # rebase
git config pull.ff uniquement        # avance rapide seulement
Vous pouvez remplacer "git config" par "git config --global" pour définir une préférence par défaut pour tous les dépôts. Vous pouvez également passer --rebase, --no-rebase ou --ff-only sur la ligne de commande pour remplacer la valeur par défaut configurée par appel.L'avertissement présente trois commandes comme options, toutes suppriment l'avertissement. Mais ils servent des objectifs différents:
git config pull.ff trueCela conserve le comportement par défaut et supprime l'avertissement.
git config pull.ff only # fast-forward onlyCela s'engage en fait au-dessus de la branche distante, en conservant une seule branche à la fois localement et à distance (contrairement au comportement par défaut où deux branches différentes sont impliquées - une sur local et l'autre sur à distance - et, pour combiner les deux, une fusion est effectuée ).
git config pull.rebase true # rebaseCela n'effectue l'extraction que si la branche locale peut être avancée rapidement. Sinon, il abandonne simplement avec un message d'erreur (et ne crée aucun commit).
Mise à jour:
Si vous avez
Git 2.29ou supérieur, vous pouvez maintenant définirpull.ffsurfalse,trueouonlypour supprimer l'avertissement.git config pull.rebase false # merge (the default strategy)
true- Il s'agit du comportement par défaut. Pull est avancé si possible, sinon il est fusionné.git config --global pull.ff only
false- Pull n'est jamais avancé et une fusion est toujours créée.git pull --ff-only
only- Pull est avancé si possible, sinon l'opération est abandonnée avec un message d'erreur.
J'apprécie le temps et les efforts que vous avez consacrés à votre réponse, mais franchement, cela m'est encore tout à fait incompréhensible.
Comme commenté ici , l'avertissement est pas affectée par si oui ou non la branche est en réalité diverge. L'initiale «Votre branche est probablement en train de diverger». peut être trompeur.
@Joe, c'est vrai. Supprimé.
Je dois dire, les trois options dans le message ne fonctionne pas pour moi SUPRESS le message. Cependant, la réponse ici ( git config --global pull.ff only ) l'a fait .
Aucune de ces options n'est excellente. pull.ff true est beaucoup plus pratique que pull.ff only - il avance rapidement quand il le peut et fusionne quand il ne le peut pas, ce qui produit moins de commits de fusion redondants que pull.rebase false . Existe-t-il un autre moyen de supprimer le message tout en conservant le pull.ff true comportement pull.ff true ?
@DiskJunky prêtez une attention particulière à la phrase suivante après les 3 options: "Vous pouvez remplacer git config par git config --global pour définir une préférence par défaut pour tous les dépôts."
Je crois que pull.rebase false est le comportement par défaut. De plus, --pull.ff fonctionne hors de la boîte si vous ne le modifiez pas. La définition de pull.rebase false conservera le comportement par défaut où pull est pull.rebase false si possible et fusionné dans le cas contraire. Voir ceci et cela
Ah! Merci @Qumber. J'avais déjà essayé pull.rebase false , mais cela ne fonctionnait pas comme décrit. Cela créait toujours un commit de fusion, et jamais d' avance rapide. La cause première était que j'avais le merge.ff false . Après avoir effacé ce paramètre, il avance rapidement quand il le devrait. Docs ici (presque identique aux docs git pull )
Sucré. Ces configurations d' pull et de merge ont tendance à se substituer à certains endroits.
Vous avez inclus l'option Git 2.29 que j'ai mentionnée ci-dessous, bon point. J'ai voté pour.
Je devais explicitement faire git config pull.ff true pour que cela prenne.
@skube je vois. Je mettrai à jour la réponse.
Ceci est un nouvel avertissement ajouté dans Git 2.27 :
git config pull.ff only # fast-forward only
Pour supprimer l'avertissement, définissez l'une des valeurs suggérées sur votre comportement par défaut préféré pour git pull si vous ne spécifiez pas de comportement sur la ligne de commande (en utilisant --ff , --ff --no-ff , --ff-only , --rebase ). Dans tous les cas, git tentera une fusion en avance rapide ( Qu'est-ce que git en avance rapide? ) Si possible. Les paramètres contrôlent ce qui se passe lorsqu'il y a des changements dans votre branche mais pas présents dans la branche distante.
git config pull.rebase true # rebase
C'est le comportement par défaut existant; réglez ceci pour aucun avertissement et aucun changement de comportement; git fusionnera la branche distante dans votre branche locale.
git config pull.rebase false # merge (the default strategy)
Ici, git tentera de rebaser vos modifications par-dessus la branche distante. Voir Quand dois-je utiliser git pull --rebase? pour plus de détails sur les raisons pour lesquelles vous pourriez vouloir cela.
* "git pull" issues a warning message until the pull.rebase configuration variable is explicitly given, which some existing users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning.
Si une fusion rapide n'est pas possible, git refusera de continuer. Comme Différence entre git pull --rebase et git pull --ff-only quotes:
Refusez de fusionner et de quitter avec un statut différent de zéro sauf si le HEAD actuel est déjà à jour ou si la fusion peut être résolue en avance rapide
C'est en fait la réponse la plus correcte, car elle explique pourquoi des gens (comme moi) voient soudainement cet avertissement après près d'une décennie d'utilisation de git. Cependant, il serait utile que des orientations soient données sur les options proposées. par exemple, faire remarquer que définir pull.ff sur "only" ne vous empêche pas de faire un "pull --rebase" pour le remplacer.
Quelle est la différence entre pull.rebase = true et branch.autoSetupRebase = always ?
@tekumara voir stackoverflow.com/a/15935584/733345
"lorsqu'il y a des changements dans votre branche mais pas présents dans la branche distante." Ensuite, il me semble que git ne devrait lancer cet avertissement que si tel est le cas. Si je tire ma ligne principale (et que la ligne principale est utilisée correctement), je ne devrais pas avoir à m'inquiéter à ce sujet.
@KeithTyler c'est raisonnable, mais comme cet avertissement est uniquement enregistré et ne provoque pas l'échec de la commande, cela pourrait signifier que vous ne le voyez qu'après que votre historique a été modifié d'une manière à laquelle vous ne vous attendez pas. L'intention est que vous preniez une décision dès le départ.
@Joe j'aime ta réponse, et je pense que c'est la bonne réponse, mais tu vois ça indépendamment du fait que git ait fait quelque chose. Je pense que le bon moment pour émettre cet avertissement est que si git doit faire quelque chose, il devrait échouer avec ce message. Pas seulement des utilisateurs de spam avec ce message dès le départ. Encore une autre chose qui contribue à ma relation amour / haine avec git.
Joe, merci pour ta réponse, ça aide beaucoup. Je ne suis pas sûr de comprendre en quoi consiste le drapeau ff uniquement. Si git pull échoue parce que ff-only est activé, que faire? À ce stade, il faut faire une fusion ou un rebase à la main pour pouvoir progresser. Donc, si le but est d'éviter les graphiques de dépendances en désordre, cela ne change rien - d'une manière ou d'une autre, automatiquement ou à la main, votre graphe de dépendances se terminera par un désordre. Je suppose que si vous devez le faire à la main, vous avez plus de contrôle dessus. Cependant, je suppose qu'en général, les gens ne sauront pas plus comment éviter un désordre que le Git lui-même.
Remarque: Auparavant, nous avons appris à " git pull " ( man ) pour avertir lorsque l'utilisateur ne dit pas que les historiques doivent être fusionnés, rebasés ou n'accepte que l' pull.ff rapide, mais l'avertissement est déclenché pour ceux qui ont défini la variable de configuration pull.ff .
Ce n'est plus le cas (c'est-à-dire: plus d'avertissement ) avec Git 2.29 (T4 2020).
Voir commit 54200ce (24 septembre 2020) par Alex Henrie ( alexhenrie ) .
(Fusionné par Junio C Hamano - gitster - dans commit 299deea , 29 septembre 2020)
pull: ne pas avertir sipull.ffa été définiSigné par: Alex Henrie
Un utilisateur qui comprend suffisamment pour définir
pull.ffn'a pas besoin d'instructions supplémentaires.
Déposez un rapport de bogue indiquant que l'avertissement prête à confusion. Une option doit être «recommandée» et l'avertissement ne doit s'afficher que sur demande et pas uniquement en raison d'un changement de version. Beaucoup de scripts automatiques pourraient maintenant rompre avec ce comportement inattendu.
@WolfgangFahl, l'avertissement ne devrait affecter aucun script car il continue de conserver le comportement par défaut jusqu'à ce qu'il soit explicitement modifié. Cela ne devrait pas amener le pull à renvoyer un code de sortie différent de zéro (étant donné que c'est un avertissement, pas une erreur). Quelques scripts CI / CD que j'ai déployés sur divers serveurs continuent de fonctionner avec le taux de réussite inchangé.
@Qumber - merci pour le commentaire. Les entrées de Crontab commenceront par exemple à envoyer des e-mails si la sortie apparaît qui n'était pas là ou pourrait être filtrée avec un simple grep. Une sortie inattendue peut avoir toutes sortes d'effets secondaires.
@WolfgangFahl, Chaque pull a généralement une sortie différente. Donc, tout script qui dépend uniquement de cela est probablement mal écrit. En outre, il ne faut pas mettre à niveau un environnement de production sans des tests approfondis. Je préfère ne pas du tout mettre à jour la production. Au lieu de cela, je crée une nouvelle instance avec tout le dernier, j'y héberge mes applications, je teste tout, puis je la fais produire.