Hai bisogno di una transizione dal mio flusso di lavoro, o rendila migliore / risolvila

4

Questo è il modo in cui lancio con git:

  1. I clone / fork qualcosa localmente
  2. Creo un nuovo ramo devel . Questo dovrebbe essere un ramo quickfix. Dovrebbe anche essere genitore di tutti i rami.
  3. Creo un ramo argomento (ad esempio, crea un nuovo tema lex )

In realtà creo qualche altro ramo secondario-argomento (diciamo lex.th2 ) per testare / vedere cose diverse.

Ma così ora, devo fare il quickfix (in devel ) una funzionalità di base (diciamo ricontrollare le credenziali del database in wp-config ).
Devo quindi passare a lex e merge devel . E poi a lex.th2 e merge lex . (In modo che le modifiche da devel possano andare lex e a lex.th2 )

Fare tutto questo rovina gravemente i miei grafici storici

Ammettocheil flusso di lavoro "ufficiale" era troppo per me e ho appena preso le parti che mi sono piaciute ... probabilmente male. Quindi qualche suggerimento su come renderlo "ordinato" pur non complicando o deviando troppo?

    
posta laggingreflex 16.07.2013 - 15:54
fonte

1 risposta

1

Dovresti imparare il comando rebase e (e come farlo interactively ). Lo faccio perché mi consente di mantenere tutte le modifiche in un grafico di revisione lineare invece di un pasticcio intricato.

Quindi ogni volta che ho un aggiornamento rapido in genere lo commetto direttamente al ramo principale. Ogni volta che lavoro su una piccola funzionalità, la impongo al master branch. Prima di spingere tutto ciò che faccio:

git pull --rebase

Questo recupera le ultime modifiche sul tuo ramo principale e rebase le tue modifiche con quello. Non mi preoccupo veramente di unire i conflitti perché mi piace prenderli a testa mentre so cosa ho fatto.

Se ho bisogno di riorganizzare i miei commit in situazioni in cui ho fatto un sacco di hotfix durante il completamento di una funzione, eseguo il comando rebase interattivo (cioè eseguo un rebase interattivo del ramo master in cima alle modifiche del telecomando di origine ramo principale):

git rebase -i origin/master

Ti verrà richiesto un file di testo con un elenco di commit come questo:

pick 1111111 Implemented feature #34
pick 2222222 Updated readme to feature #34
pick 3333333 FIX: something works now
# ... a bunch of commands listed below

L'ordine dei commit è dall'alto verso il basso. Ma posso riorganizzarli nel modo in cui li voglio:

# moved commit 3333333 first will be applied first in the 
pick 3333333 FIX: something works now

# I want feature #34 to be one commit so I do it like this:
pick 1111111 Implemented feature #34
squash 2222222 Updated readme to feature #34
# squash will squash commits 1111111 2222222 to one commit 
# and prompt for a new commit message using both as template

Salva e chiudi e il rebase viene eseguito in base al file di testo. In questo modo git manterrà tutto bello e ordinato nel modo in cui lo vuoi ... nel mio caso una lunga coda di modifiche dritte da spingere.

Ci sono momenti in cui creo i branch degli argomenti, ma faccio la stessa cosa prima di unirmi al master. Cioè rebase le modifiche sul ramo dell'argomento con il master e quindi rebase in modo interattivo se voglio riordinarlo.

Potrebbe sembrare una brutta cosa riscrivere la storia in questo modo, ma finché non hai spinto le modifiche puoi fare quello che vuoi con esso. Questo è il motivo per cui raramente ho un ramo devel ; il tuo ramo master locale è già il tuo ramo devel . Finché non hai inserito nulla, è disponibile solo nel tuo repository.

    
risposta data 16.07.2013 - 16:44
fonte

Leggi altre domande sui tag