Il commit frequente previene i conflitti di fusione?

Rendere diversi piccoli commit piuttosto che uno grosso non previene magicamente i conflitti, ma di solito li rende meno frequenti e più facili da gestire.

Se commetti e spingi molte piccole modifiche per diventare master, allora è più difficile che sorgano dei conflitti, poiché meno codice sta cambiando tra i commit e gli altri sviluppatori vedranno alcune delle tue modifiche prima che inizino a fare il loro proprio.

Se hai un ramo di funzionalità suddiviso in un sacco di piccoli commit quando si uniscono, quindi l'unione viene eseguita un commit alla volta, quindi se ci sono molti conflitti, devi solo risolvere il valore di un commit di conflitti alla volta, che di solito è molto più facile che risolverli tutti in una volta.

Il comando git merge non esegue alcun commit, ad eccezione di un singolo "merge commit" se necessario. Non dividerà retroattivamente un commit esistente in diversi commit più piccoli o qualcosa di simile (non credo che ci sia un modo semplice per farlo in git, o qualsiasi altro VCS).

Non una risposta diretta, solo la pratica che funziona meglio per me:

• Avere un repository centrale con un ramo master in esso.
• Clona / tira il ramo principale del repository centrale prima di assumere una nuova attività / biglietto / funzione.
• Mentre vai, fai spesso dei commit locali.
• Dopo ogni commit, o almeno periodicamente, fai un git pull --rebase . Questo metterà il tuo lavoro attuale in cima allo stato più recente del master. Dato che lo fai spesso, le unioni automatiche di solito sono sufficienti. Quando sorgono dei conflitti, essi sorgeranno sul tuo ramo e si spera siano piccoli.
• Quando hai finito e sei pronto a spingere la tua funzionalità, hai zero conflitti, per definizione.

Di solito non lavoro sul ramo master localmente ma invece creo un ramo con nome separato (o diversi, provo vari approcci); questo mi impedisce di spingere accidentalmente.

Ancora meglio se si dispone di uno strumento di revisione del codice come Gerrit installato e il proprio repository principale non può essere spinto direttamente su (solo tramite la revisione del codice).

I conflitti di commit e fusione frequenti sono indipendenti l'uno dall'altro. Impegnandoti spesso a ridurre la probabilità di un conflitto di unione, non puoi eliminarlo. Se due persone clonano un repository, cambiano la stessa riga in un file, eseguono il commit e lo spingono, quindi determinerà un conflitto di unione. Non importa quanto fossero veloci.