Come posso inviare una patch a un altro sviluppatore ed evitare conflitti di unione?

Question

Come posso ottenere una patch da un commit per inviarla a un altro sviluppatore? E come posso evitare un conflitto di unione con questa patch quando unisco i nostri alberi in un secondo momento?

Se sai come spiegare per favore come farlo nel tuo VCS di tua scelta come sovversione, git, Mercurial, bzr o ecc.

Answer 1

In git puoi reindirizzare l'output di git-diff tra due commit in questo modo:

git diff fa1afe1 deadbeef > patch.diff

Invia il patch.diff allo sviluppatore e lascialo git-apply sul suo spazio di lavoro in questo modo:

git apply patch.diff

Se l'altro sviluppatore ha già i commit disponibili nel suo repository, potrebbe sempre inserirlo in se stesso senza fondersi in questo modo:

git apply < git diff fa1afe1 deadbeef

È quindi possibile aggiungere e < a href = "http://www.kernel.org/pub/software/scm/git/docs/git-commit.html" rel = "noreferrer"> commit le modifiche nel diff nel solito modo .

---

Ora ecco la parte interessante quando devi ricollegare la patch al ramo principale (che è pubblico). Considera il seguente albero di revisione in cui C * è la patch applicata da C nel ramo master:

A---B---C---D          master, public/master
     \
      E---C*---F       feature_foo

Puoi utilizzare git-rebase per aggiornare il ramo dell'argomento (in questo esempio denominato feature_foo ) con la sua testa a monte. Ciò significa che quando si digita quanto segue:

git rebase master feature_foo

Git riorganizzerà l'albero di revisione in questo modo e applicherà anche la patch stessa:

A---B---C---D          master, public/master
             \
              E*---F*  feature_foo

L'unione al ramo a monte sarà ora una semplice fusione rapida. Controlla anche che i nuovi commit E * e F * funzionino rispettivamente come i precedenti E e F .

Puoi fare la stessa cosa contro un altro ramo dello sviluppatore usando gli stessi passaggi ma invece di farlo su un repository pubblico, sarai recupero revisioni dal repository degli sviluppatori. In questo modo non dovrai chiedere una patch all'altro sviluppatore se è già disponibile da ciò che ha pubblicato nel suo repository.

Nota: non riformulare mai un ramo pubblico perché il comando riscriverà la cronologia di git che è qualcosa che non vuoi fare sui rami da cui le persone dipendono e creerà un disastro quando si uniscono al remoto repository. Inoltre, non dimenticare mai di integrarti spesso in modo che altri membri del tuo team possano prendere parte alle tue modifiche.

Answer 2

In SVN puoi semplicemente apportare le modifiche prima di eseguire il commit, inoltra l'output del svn diff a un file in quanto tale

svn diff > mypatch.diff

puoi quindi ripristinare le modifiche e applicare la patch in un secondo momento utilizzando

patch -p0 -i mypatch.diff

Come sempre non applicare ciecamente patch al codice e ispezionarle sempre per prime.

Potresti anche scoprire che la patch romperà il tuo codice sorgente se i file sorgente sono cambiati abbastanza significativamente da quando la patch è stata presa.

Inoltre, non è possibile garantire che non si verifichino conflitti di unione quando si tenta di verificare il codice.

Answer 3

Bzr gestisce l'invio di una "direttiva di unione", il che significa che invia la patch per te in modo che l'altra parte possa semplicemente fare clic su " OK " per unire e c'è meno inutile in giro con patch / applica ecc.

solo:  $ bzr invia -o mycode.patch

Answer 4

In Subversion non esiste un modo carino per farlo. Sì, puoi usare svn diff + patch ma questo rimanderà i tuoi problemi solo fino a quando non ti unirai e allora è probabile che te ne sia dimenticato.

Il modo in cui lo faresti in Subversion sarebbe quello di creare un ramo, eseguire il commit sul ramo e chiedere al destinatario della patch di passare al ramo. Quindi puoi unire il ramo al tronco nel solito modo.