Negli ultimi 3 anni ho usato git quasi quotidianamente per tutti i miei progetti per animali domestici e al lavoro per piccoli progetti che non erano nel repository SVN globale. Il mio flusso di lavoro è abbastanza simile al famoso modello di branching git del link per riassumere:
-
Lavoro nei rami, un ramo per una funzione (non confondendo il bugfix con la nuova funzione, ecc.)
-
Mi impegno davvero molto spesso, spesso solo 2-5 righe, i commit più grandi sono di solito nuove funzioni ecc. Uso intensamente lo strumento di commit interattivo per organizzare semanticamente i miei commit (cioè mentre aggiusti una dichiarazione di importazione e qualcosa in un funzione, tendo a dividerlo in due quando le modifiche non sono correlate).
-
Infine, tendevo a usare
git mergecon l'opzione--no-ff, perché in un certo senso mi piace il grafico della cronologia delle diramazioni visive in gitk. -
Mai usato davvero il rebasing (tranne per le correzioni)
Naturalmente questo flusso di lavoro non ha mai dovuto affrontare conflitti di fusione così seri come i team che lavorano sulla stessa base di codebase.
Ora ho letto qua e là, che alcuni progetti sono molto preoccupati di mantenere una storia "avanti veloce". Perché è così importante? Qual è la tua scelta in tal senso?
Posso immaginare che una storia "lineare" sia più facile da gestire quando si guardano le storie, ma: è anche utile avere la vera storia secondo me. La storia lineare senza fast-forward è più simile alle storie SVN forse, ma i miei commit git sono solitamente molto più piccoli del commit SVN medio, questi sono - penso - più paragonabili a un branch-merge in git (almeno il mio utilizzo ). Lavorare senza -no-ff farebbe un po 'di "ingombrare" la cronologia nel master (questa è la mia preoccupazione per le unioni rapide).