Comment faire en sorte que Git pull utilise le rebase par défaut pour tous mes dépôts?

186

Existe-t-il un moyen de configurer le référentiel Git hôte de sorte que tout ce qui est git pullfait à partir de ses clones (locaux) l'utilise --rebasepar défaut? En cherchant sur Stack Overflow, j'ai appris branch.autosetuprebase, mais il doit être configuré individuellement par clone.

Mon flux de projet est configuré de telle sorte que nous effectuons pullune developbranche avant d'y mergeinsérer une fonctionnalité. Cela pullutilise presque toujours --rebase, donc j'essaie de déterminer si cela peut être la valeur par défaut.

Homme masqué
la source
6
Pourquoi veux-tu ça? Je pense qu'il est plus raisonnable d'apprendre aux utilisateurs à réfléchir activement au cas le plus approprié (en fonction de l'ampleur des changements qu'ils ont apportés ou attendus de l'amont) ''
Jonas Schäfer
4
@JonasWielicki Oui, je suis d'accord. C'est juste que certains membres de mon équipe sont nouveaux sur Git, et j'aimerais savoir s'il existe un moyen de l'appliquer pour éviter les problèmes pendant la phase initiale (jusqu'à ce qu'ils l'aient appris). L'équipe travaille également à distance dans un fuseau horaire différent, ce qui signifie qu'elle serait bloquée pendant plusieurs heures en cas de problème. Juste curieux de savoir si cela est possible.
Masked Man
1
Je pense qu'en particulier pour les configurations initiales, il vaut mieux opter pour la fusion. Rebase fait des choses beaucoup plus étranges si votre code diverge vraiment. Vous devez résoudre les mêmes conflits encore et encore jusqu'à ce que vous poussiez. Donc, si un membre de l'équipe veut travailler sur du code, utilise toujours le rebase et ne pousse pas jusqu'à ce qu'il ait terminé (ce que les nouveaux arrivants peuvent faire, au lieu de se ramifier eux-mêmes), ils seront confrontés aux mêmes conflits qu'ils ont déjà résolus X fois. .
Jonas Schäfer
3
@JonasWielicki Les membres de l' équipe font faire une nouvelle branche pour chaque nouvelle fonctionnalité qu'ils travaillent sur (et cela, ils ont déjà compris assez bien). Le besoin de rebase vient du fait que d'autres développeurs se sont engagés dans la branche de développement «à distance» au moment où il est prêt à pousser ses modifications. Par conséquent, j'aimerais qu'il fasse un pull rebase à distance avant de pousser ses modifications. Le projet lui-même est assez mature, seule l'équipe est nouvelle. :) Donc c'est une "configuration initiale" uniquement en termes de personnes. Quel serait votre conseil pour ce scénario?
Masked Man du
5
En réponse à votre premier commentaire, dans la majorité des cas (presque tous), le rebase est le bon choix, car il faut beaucoup de temps pour tester en profondeur une nouvelle fonctionnalité, etc. Au moment où cela sera fait, il y aurait certainement beaucoup de commits d'autres développeurs.
Masked Man

Réponses:

205

Il existe maintenant 3 niveaux de configuration différents pour le comportement d'extraction par défaut. Du plus général au plus fin, ils sont:

1. pull.rebase

Définir ceci sur truesignifie que cela git pulléquivaut toujours à git pull --rebase(sauf s'il branch.<branchname>.rebaseest explicitement défini sur false). Cela peut également être défini par référentiel ou globalement.

2. branch.autosetuprebase

Le paramétrer sur alwayssignifie que chaque fois qu'une branche de suivi est créée, une entrée de configuration comme celle ci-dessous sera créée pour elle. Pour un contrôle plus fin, cela peut également être défini sur never, localou remoteet peut être défini par référentiel ou globalement. Voir git config --helppour plus de détails.

3. branch.<branchname>.rebase

Définir ceci sur truesignifie que cette branche particulière tirera toujours de son amont via le rebasage, sauf si elle git pull --no-rebaseest utilisée explicitement.

Conclusion

Ainsi, même si vous ne pouvez pas modifier le comportement par défaut pour tous les futurs clones d'un référentiel, vous pouvez modifier la valeur par défaut pour tous les référentiels de l'utilisateur actuel (existants et futurs) via git config --global pull.rebase true.

Parker Coates
la source
4
Merci pour votre réponse. J'explorais si je pouvais avoir un paramètre pour que quiconque clone le référentiel l'ait activé par défaut. Le paramètre ci-dessus serait stocké dans ~/.gitconfig, ce qui signifie que chaque développeur qui clone le référentiel hôte devra exécuter la commande. Ne pas se plaindre de votre solution. Il est bon, je veux juste confirmer que j'ai bien compris votre point.
Masked Man
Merci d'avoir répondu. Il semble en effet que c'est aussi proche que possible.
Masked Man
139

Que diriez-vous

git config --global pull.rebase true

Cela dira à git de toujours tirer avec rebase.

Mackuntu
la source
3
Merci, cela fonctionne très bien pour les branches de suivi existantes.
Fls'Zen
1
Veuillez supprimer --bool, il est inutile
diralik
38

La réponse est non.

Il n'y a pas de moyen de configurer un référentiel distant afin que tous ceux qui le clonent aient le comportement par défaut de git pullchangé.

Vous pouvez cependant configurer un hook côté serveur qui vérifie que personne ne pousse les validations de fusion ( quelque chose comme ça , peut-être).

Il existe également des options de configuration qui pourraient vous intéresser. Tous les développeurs qui clonent à partir du référentiel distant devront le définir eux-mêmes manuellement.

1. Option branch.<name>.rebase

Vous pouvez configurer une branche locale pour qu'elle utilise toujours --rebase, comme ceci, en remplaçant <name>par un nom de branche:

git config branch.<name>.rebase true

Après avoir exécuté ceci master, la mastersection .git/configressemblait à ceci:

[branch "master"]
    remote = origin
    merge = refs/heads/master
    rebase = true

2. Option branch.autosetuprebase

Exécuter cette commande de configuration précédente pour chaque branche Git peut être un problème, vous pouvez donc configurer Git pour le configurer automatiquement pour chaque nouvelle branche:

git config branch.autosetuprebase always

(Vous pouvez également spécifier never, remoteet local, voir man git-configpour plus de détails.)

Sans cette --globaloption, la configuration est enregistrée dans .git/configet seul le référentiel actuel est affecté. Avec --global, la configuration est enregistrée dans ~/.gitconfiget chaque référentiel non configuré est affecté.

Cette option n'affecte pas les branches déjà existantes.

3. Option pull.rebase

git config --bool pull.rebase true

(Vous pouvez également lui donner l' --globaloption.)

Si cette option est vraie, l'exécution git pulléquivaut à git pull --rebase, sauf si elle branch.<name>.rebasea été définie sur false.

Flimm
la source
3

Cela fait de l' --rebaseoption la valeur par défaut lors de l'émission d'un git pull sur une branche donnée.

@Flimm, j'avais besoin d'ajouter truepour que votre première option fonctionne.

La syntaxe correcte est donc:

git config branch.<branch>.rebase true

Pour exécuter cette commande sur la developbranche:

git config branch.develop.rebase true

Et maintenant, la developsection de .git/configressemble à ceci:

[branch "develop"]
        remote = origin
        merge = refs/heads/develop
        rebase = true
Daishi
la source
Merci, j'ai modifié ma réponse, à l'avenir, n'hésitez pas à modifier la réponse vous-même.
Flimm
2
Donwvoter, qui que vous soyez, veuillez expliquer vos raisons. Le vote négatif sans commentaire me semble complètement arbitraire et peu constructif.
Daishi
1

Il n'existe actuellement aucun moyen de définir la stratégie par défaut pour un référentiel.

Si vous le voulez pour vous-même et que vous utilisez au moins git 1.7.9, vous pouvez définir globalement la pull.rebaseconfiguration comme suit:

git config --global pull.rebase true

Mais vous devrez le faire sur chaque machine. Une option pourrait être de configurer le modèle / squelette d'accueil de l'utilisateur par défaut avec cette option. Les utilisateurs peuvent toutefois modifier cette option.

Si vous ne voulez pas de fusions, vous pouvez définir un hook côté serveur pour rejeter les poussées avec des fusions.

Pour votre information, il s'agit de la documentation source de pull.rebase:

Quand c'est vrai, rebase les branches au-dessus de la branche récupérée, au lieu de fusionner la branche par défaut de la télécommande par défaut lorsque "git pull" est exécuté. Voir "branch..rebase" pour définir ceci sur une base par branche.

Lors des fusions, passez l'option --rebase-merges à git rebase afin que les commits de fusion locaux soient inclus dans le rebase (voir git-rebase pour plus de détails).

Lors de la conservation, transmettez également --preserve-merges à git rebase afin que les commits de fusion validés localement ne soient pas aplatis en exécutant git pull.

Lorsque la valeur est interactive, le rebase est exécuté en mode interactif.

REMARQUE: il s'agit d'une opération potentiellement dangereuse; ne l'utilisez pas si vous n'en comprenez pas les implications (voir git-rebase pour plus de détails).

David
la source