Come fare in modo che Git pull utilizzi rebase per impostazione predefinita per tutti i miei repository?


186

Esiste un modo per configurare il repository Git host in modo che qualsiasi operazione git pulleseguita dai suoi cloni (locali) venga utilizzata --rebaseper impostazione predefinita? Cercando su Stack Overflow, ho appreso branch.autosetuprebase, ma deve essere configurato individualmente per clone.

Il flusso del mio progetto è impostato in modo tale che noi pullil developramo prima di mergeinserire un ramo di funzionalità ad esso. Questo lo pullusa quasi sempre --rebase, quindi sto cercando di capire se questo può essere il valore predefinito.


6
Perché lo vuoi? Penso che sia più ragionevole insegnare agli utenti a pensare attivamente a quale caso sarà più appropriato (in base all'entità dei cambiamenti che hanno fatto o si aspettano da monte) "
Jonas Schäfer,

4
@JonasWielicki Sì, sono d'accordo. È solo che alcuni dei membri del mio team sono nuovi in ​​Git e vorrei sapere se esiste un modo per applicarlo per evitare problemi durante la fase iniziale (fino a quando non l'avranno appreso). Il team lavora anche in remoto in un fuso orario diverso, il che significa che sarebbero bloccati per diverse ore se qualcosa andasse storto. Solo curioso di sapere se questo è possibile.
Masked Man,

1
Penso soprattutto per le configurazioni iniziali, è meglio andare per unire. Rebase rende le cose molto più strane se il tuo codice diverge davvero. Devi risolvere gli stessi conflitti più e più volte finché non spingi. Quindi, se un membro del team vuole lavorare su un po 'di codice, usa sempre rebase e non spinge fino a quando non ha finito (cosa che i nuovi arrivati ​​potrebbero fare, invece di ramificarsi), dovranno affrontare gli stessi conflitti che hanno già risolto X volte .
Jonas Schäfer,

3
@JonasWielicki I membri del team fanno fare una nuova filiale per ogni nuova funzione lavorano su (e questo, hanno già capito abbastanza bene). La necessità di rebase viene perché altri sviluppatori si sono impegnati nel ramo di sviluppo "remoto" quando è pronto a spingere i suoi cambiamenti. Quindi, vorrei che facesse un pull rebase da remoto prima di spingere i suoi cambiamenti. Il progetto in sé è abbastanza maturo, solo il team è nuovo. :) Quindi è una "configurazione iniziale" solo in termini di persone. Quale sarebbe il tuo consiglio per questo scenario?
Masked Man,

5
Rispondendo al tuo primo commento, nella maggior parte dei casi (quasi tutti), rebase è la scelta giusta, dal momento che ci vuole molto tempo per testare a fondo una nuova funzionalità, ecc. Al momento, ci sarebbe sicuramente molti impegni da parte di altri sviluppatori.
Masked Man,

Risposte:


205

Ora ci sono 3 diversi livelli di configurazione per il comportamento pull predefinito. Dal più generale al più fine sono:

1. pull.rebase

Impostarlo su truesignifica che git pullè sempre equivalente a git pull --rebase(a meno che non branch.<branchname>.rebasesia esplicitamente impostato su false). Questo può anche essere impostato per repository o globalmente.

2. branch.autosetuprebase

L'impostazione su questo alwayssignifica che ogni volta che viene creato un ramo di tracciamento, verrà creata una voce di configurazione come quella seguente. Per più sofistica controllo, questo può anche essere impostato never, localoppure remotee può essere impostato per ogni repository o globalmente. Vedi git config --helpper ulteriori dettagli.

3. branch.<branchname>.rebase

Impostando questo su truesignifica che quel particolare ramo tirerà sempre dal suo monte attraverso il rebasing, a meno che non git pull --no-rebasesia usato esplicitamente.

Conclusione

Pertanto, sebbene non sia possibile modificare il comportamento predefinito per tutti i cloni futuri di un repository, è possibile modificare il valore predefinito per tutti i repository dell'utente (esistenti e futuri) tramite git config --global pull.rebase true.


4
Grazie per la risposta. Stavo esplorando se potevo avere un'impostazione in modo che chiunque cloni il repository abbia abilitato per impostazione predefinita. L'impostazione di cui sopra verrebbe memorizzata ~/.gitconfig, il che significa che ogni sviluppatore che clona il repository host dovrebbe eseguire il comando. Non lamentarti della tua soluzione. È buono, voglio solo confermare di aver capito bene il tuo punto.
Masked Man,

Grazie per la risposta. Sembra davvero che questo sia il più vicino possibile.
Masked Man

139

Che ne dite di

git config --global pull.rebase true

Questo dirà a git di tirare sempre con rebase.


3
Grazie, funziona alla grande per le filiali di tracciamento esistenti.
Fls'Zen,

1
Rimuovi --bool, non è necessario
diralik

38

La risposta è no.

Non esiste un modo per impostare un repository remoto in modo tale che chiunque lo cloni abbia il comportamento predefinito git pullmodificato.

È possibile, tuttavia, impostare un hook sul lato server che verifica che nessuno spinga i commit di merge ( qualcosa del genere , forse).

Ci sono anche alcune opzioni di configurazione che potrebbero interessarti. Tutti gli sviluppatori che clonano dal repository remoto dovranno impostarlo manualmente.

1. Opzione branch.<name>.rebase

È possibile configurare un ramo locale da utilizzare sempre --rebase, in questo modo, sostituendolo <name>con un nome di ramo:

git config branch.<name>.rebase true

Dopo averlo eseguito master, la mastersezione in .git/configappariva così:

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

2. Opzione branch.autosetuprebase

L'esecuzione del comando di configurazione precedente per ogni ramo Git può essere una seccatura, quindi puoi configurare Git per configurarlo automaticamente per ogni nuovo ramo:

git config branch.autosetuprebase always

(È possibile anche specificare never, remotee local, vedi man git-configper maggiori dettagli.)

Senza l' --globalopzione, la configurazione viene salvata .git/confige solo il repository corrente è interessato. Con --global, la configurazione viene salvata ~/.gitconfige ogni repository non configurato viene interessato.

Questa opzione non influisce sulle filiali già esistenti.

3. Opzione pull.rebase

git config --bool pull.rebase true

(Puoi anche dargli l' --globalopzione.)

Se questa opzione è vera, l'esecuzione git pullè equivalente a git pull --rebase, a meno che non branch.<name>.rebasesia stata impostata su false.


3

Ciò rende l' --rebaseopzione predefinita quando si emette un git pull ramo specifico.

@Flimm, dovevo aggiungere trueper far funzionare la tua prima opzione.

Quindi la sintassi corretta è:

git config branch.<branch>.rebase true

Per eseguire questo comando sul developramo:

git config branch.develop.rebase true

E ora la developsezione in .git/configè simile a questa:

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

Grazie, ho modificato la mia risposta, in futuro, sentiti libero di modificare tu stesso la risposta.
Flimm,

2
Donwvoter, chiunque tu sia, ti preghiamo di spiegare le tue ragioni. Il downvoting senza un commento mi sembra del tutto arbitrario e non costruttivo.
Daishi,

1

Attualmente non è possibile impostare la politica predefinita per un repository.

Se lo vuoi per te stesso e usi almeno git 1.7.9, puoi impostare la pull.rebaseconfigurazione a livello globale come segue:

git config --global pull.rebase true

Ma dovrai fare su ogni macchina. Un'opzione potrebbe essere quella di configurare il modello / scheletro home utente predefinito con quell'opzione. Gli utenti potrebbero, tuttavia, modificare questa opzione.

Se non si desidera unire, è possibile definire un hook sul lato server per rifiutare i push con le unioni.

Per tuo riferimento, questa è la documentazione di origine per pull.rebase:

Se vero, rebase i rami sopra il ramo recuperato, invece di unire il ramo predefinito dal telecomando predefinito quando viene eseguito "git pull". Vedere "branch..rebase" per impostarlo in base al ramo.

Quando si fondono, passare l'opzione --rebase-merges per git rebase in modo che i commit di unione locale siano inclusi nel rebase (vedere git-rebase per i dettagli).

Se preservato, passa anche --preserve-merges insieme a git rebase in modo che i commit di merge impegnati a livello locale non vengano appiattiti eseguendo git pull.

Quando il valore è interattivo, il rebase viene eseguito in modalità interattiva.

NOTA: questa è un'operazione forse pericolosa; non usarlo a meno che tu non abbia compreso le implicazioni (vedi git-rebase per i dettagli).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.