Come incoraggiare i contributori a scegliere il rebasing rispetto alla fusione?

Richiedi messaggi di commit significativi

Il problema non deriva dall'uso di commit merge invece di rebase in questo caso particolare. È la mancanza di messaggi di commit significativi. Ad esempio, senza vedere il tuo repository, questo potrebbe benissimo essere un commit di unione:

 Ron Cosby       PROJ-15711: Fix the jsdoc template

Ma contrariamente agli altri commit, questo ha un significato chiaro. Allo stesso modo, immagina di avere:

 Vadym Malan     Rebase

Questo commit di rebase è lo stesso tipo di rumore di quando l'unione corrente esegue commit ( modifica: supponendo che questo sia stato ottenuto commettendo collisioni e modificando il messaggio, ovviamente). Certo, il design degli strumenti è tale che i commessi di unione hanno messaggi automatici e rebase no, ma questo non è in alcun modo un argomento per costringere le persone a usare rebase, perché il rebasing non impedisce automaticamente di avere rumori nella cronologia.

È più facile eseguire l'unione senza pensare a un messaggio, perché esiste un messaggio predefinito per le unioni. Ad esempio, in origine, git non attivava nemmeno l'editor per i messaggi di fusione, che era riconosciuto come essere un errore di progettazione :

[...] my main issue is that git makes it way too easy to have bad merge messages.

^{(Linus Torvalds)}

Questo è stato corretto , ma ancora, il messaggio predefinito non dovrebbe essere usato Nota anche che il messaggio predefinito in git indica almeno quali rami vengono uniti, il che potrebbe fornire più informazioni che semplicemente "Unisci".

Also, merges to my understanding are not completely cheap in terms of disk space.

No, sono economici quanto i commit regolari, non preoccuparti. Per essere più precisi, anche se occupano più spazio, questo non è importante. Non decidi di rebase invece di eseguire un commit di unione perché potrebbe farti risparmiare un paio di byte.

Qual è la pertinenza della tua domanda?

Hai detto:

People are choosing merges because it is the cheapest strategy for syncing. If some other strategy will work for them and be more pleasant - they'll just switch to it.

Immagina di dire alla tua squadra:

"Team, from now on we want to have descriptive commit messages. Yes, Ron, that includes merge commits. You better follow this policy, or else* ..."

(* questa parte è facoltativa)

Quindi, i tuoi dipendenti orientati alla fusione saranno:

• vederlo come un peso e decidere di rebase invece
• oppure, sono a posto con la nuova politica e scriveranno buoni messaggi di commit.

Vinci in entrambi i casi.

Un modo per "nascondere" i set di cambiamento di unione è utilizzare Mercurial Queues . È un'estensione attualmente distribuita insieme a Mercurial.

In breve, sono insiemi di modifiche mutabili, note come patch in una coda di patch. Invece di dover unire, i tuoi utenti possono rebase e quindi applicare la patch o le patch che vogliono spingere sulla punta del rebase, finalizzare le patch e spingere.

Devi ancora educare i tuoi utenti a utilizzare correttamente la coda di patch.

Forse c'è un motivo diverso per i tuoi utenti di unire ...

Un sistema di controllo della versione distribuito come Mercurial implica la fusione, ovvero l'intera idea di esso. Le persone possono lavorare senza connessione e in un secondo momento fondere il loro lavoro nel ramo principale. Mercurial semplifica la fusione, quindi non sono sorpreso che i tuoi utenti lo usino: è il percorso per non resistere.

Anche l'unione è (quasi) impossibile da prevenire. Supponiamo che tutti i tuoi utenti abbiano installato un hook di commit che verifica l'upstream prima di eseguire il commit. Quindi gli utenti devono rebase prima che possano eseguire il commit e quindi impedire l'unione. Se due utenti rebase prima e poi eseguono il commit allo stesso tempo (che è consentito dal hook di commit), uno di questi dovrà ancora unirsi.

Per impedire ciò, un certo numero di team nel mio posto di lavoro corrente usa commit & spingere i gettoni. Solo la persona che possiede il token, è autorizzato a impegnarsi e quindi a spingere. Ciò impedisce l'unione (almeno per la maggior parte del tempo).

In uno dei miei posti di lavoro precedenti, usavano un gatekeeper. Il repository centrale era sempre chiuso. Solo quando il tuo codice è stato rivisto e approvato (questo comportava un documento ufficiale che richiedeva firme di più persone), il gatekeeper ti ha permesso di eseguire il commit e il push. Questo è stato un processo molto elaborato.

Vedete, ci sono diversi modi per impedire la fusione; -)