Git Cherry-pick vs Merge Workflow


Answers

A mio parere, il cherry-picking dovrebbe essere riservato per le rare situazioni in cui è richiesto, ad esempio se hai fatto qualche correzione direttamente sul ramo "master" (trunk, ramo di sviluppo principale) e poi hai capito che dovrebbe essere applicato anche a "maint" '. Dovresti basare il flusso di lavoro sia su unione, sia su rebase (o "git pull --rebase").

Ricorda che il commit selezionato o rebased è diverso dal punto di vista di Git (ha un identificatore SHA-1 diverso) rispetto all'originale, quindi è diverso dal commit nel repository remoto. (Di solito Rebase si occupa di questo, poiché controlla id di patch, ovvero le modifiche, non un id di commit).

Inoltre in git puoi unire più rami contemporaneamente: i cosiddetti polpo si uniscono . Nota che la fusione di polpo deve avere successo senza conflitti. Tuttavia potrebbe essere utile.

HTH.

Question

Supponendo che io sia il manutentore di un repository, e voglio apportare modifiche da un contributore, ci sono alcuni possibili flussi di lavoro:

  1. cherry-pick ogni commit dal telecomando (in ordine). In questo caso git registra il commit come non correlato al ramo remoto.
  2. merge il ramo, inserendo tutte le modifiche e aggiungendo un nuovo commit "conflitto" (se necessario).
  3. merge ogni commit dal ramo remoto individualmente (sempre in ordine), consentendo di registrare i conflitti per ogni commit, invece di raggrupparli tutti insieme come uno.
  4. Per completezza, potresti fare un rebase (come l'opzione cherry-pick ?), Tuttavia la mia comprensione è che ciò può causare confusione per il contributore. Forse elimina l'opzione 1.

In entrambi i casi 2 e 3, git registra la storia del ramo dei commit, a differenza di 1.

Quali sono i pro ei contro tra l'uso dei metodi cherry-pick o merge descritti? La mia comprensione è che il metodo 2 è la norma, ma ritengo che la risoluzione di un grosso commit con una singola unione "di conflitto" non sia la soluzione più pulita.




Links