git safe rebase o "try rebase, fallback to merge"

Question

Sto pensando di trasformare il mio unione solo flusso di lavoro per utilizzare rebase più spesso. In questo caso specifico, sono l'unico sviluppatore, ma lavoro su più piattaforme, spesso modificando gli stessi file per parti specifiche della piattaforma, in genere con modifiche non in conflitto. Ma sono un po 'incerto su questo, a causa del dibattito su git merge vs git rebase e sulla loro sicurezza (per esempio vedere this vs. this, le due risposte principali di a question).

Domanda: come fare qualcosa di simile in seguito, con l'obiettivo di "sicuro", ma ancora più pulito possibile tirare/rebase/merge:

• Se ci sono non-spinto commit, poi git pull --rebase fino la prima operazione di unione che è in conflitto con la cronologia locale.
• Quindi git pull --no-rebase per unire il resto ed eseguire la risoluzione dei conflitti.
• È possibile tornare indietro a rebasing per le ultime modifiche non in conflitto, in modo da mantenere la parte parallela della cronologia più corta possibile.

Quindi se non ci sono conflitti, il risultato finale sarebbe pull con rebase e bella cronologia lineare. Se ci sono conflitti, le unioni saranno visibili, ma la cronologia parallela sarà il più breve possibile.

Ciò è possibile con un semplice comando git semplice o due, con interruttori di destra (che potrei scrivere in uno script pull o alias)? In caso contrario, è possibile con qualche strumento esistente?

Un altro modo di guardare a questa domanda: voglio automatizzare la decisione di scegliere REBASE o unire, quindi non ho bisogno di pensare a quel dettaglio quando si fa tirare.

Inoltre, questo ha senso? :)

Answer 1

Seguo quello che stai suggerendo. Prima provo un rebase, e se non ci sono conflitti, allora funziona e la tua cronologia è molto più pulita. Se c'è un conflitto faccio unire.

L'unica differenza è che non proverei a suddividere l'unione e rebase tra i commit di un pull come suggerisci nel terzo punto del punto elenco. In effetti, non sono sicuro che abbia senso. Sembra lo stesso risolvere i conflitti e fare rebase continue quando si risolvono i conflitti. Il risultato sarebbe lo stesso di un rebase con conflitti.

Se sono necessarie modifiche da spingere. O fare un rebase o, se ci sono conflitti, fare unire.