Messaggio di commit post-merge Hg, best practice?

Question

mi ritrovo a fare la seguente molto:

C:\Code>hg pull 
pulling from http://server/FogBugz/kiln/Repo/Project/Rebuild/trunk 
searching for changes 
adding changesets 
adding manifests 
adding file changes 
added 2 changesets with 4 changes to 4 files (+1 heads) 
(run 'hg heads' to see heads, 'hg merge' to merge) 

C:\Code>hg merge 
4 files updated, 0 files merged, 0 files removed, 0 files unresolved 
(branch merge, dont forget to commit) 

C:\Code>hg commit -m "Merged" 

C:\Code>hg push 
pushing to http://server/FogBugz/kiln/Repo/Project/Rebuild/trunk 
searching for changes 
remote: kiln: successfully pushed 2 changesets 

La mia domanda è: che cosa è una migliore/più utile messaggio di commit da utilizzare dopo la fusione un pull dal repository. Ci sono delle best practice che le persone usano nei sistemi di controllo delle versioni distribuite per questo genere di cose?

Answer 1

Se si utilizza il fetch extension automatizza il pull, unisce passo in un passo, preleva. Il messaggio che genera automaticamente è qualcosa sulla falsariga di "unione automatica". Gli sviluppatori di hg sembrano ritenere che ciò sia ragionevole in quanto l'estensione è ora distribuita con la base.

I messaggi di unione non sembrano contenere una quantità particolarmente elevata di informazioni. Il tuo messaggio sembra ragionevole.

[[offtopic, a volte li usano come un'opportunità per un gioco di parole sulla parola fusione]]

Answer 2

Non c'è un modo, ecco cosa ho cercato di rispettare.

Su messaggi di commit:

Jus ricordare che quei messaggi sono gli unici stringhe che si avrebbe collegato a qualcuno che è cercare di decifrare i motivi della commettere.

La chiave è fornire una descrizione che sarà un utile commento sullo sviluppo del codice. Quindi quando qualcuno usa hg log, ha un bel commento su come si sta sviluppando il software.

Alcune buone pratiche:

collegarlo con il sistema di gestione dei bug:

1. correzioni # 3456, nuova funzione # 2435 ecc
2. o più descrittivo uno dei quali cambiamenti si sta portando in il repo
3. Dare crediti

In effetti, quello che faccio per lo più è. Guarda lo stato corrente di "hg log" e vedi quale messaggio utile significherebbe una progressione logica nella comprensione dell'ultimo commit.

Answer 3

Si potrebbe utilizzare l'estensione rebase, così hg pull --rebase sarebbe rebase tuo repo alla punta del repo centrale. Ciò nega la necessità di fondersi dopo un tiro.

ho aggiunto un alias per esso:

[alias] 
pure = pull -u --rebase 

funziona bene per noi.

Ulteriori dettagli sono disponibili nella pagina RebaseProject.

Answer 4

Per le fusioni banali, dove lavori solo con un repository, penso che "unire" sia corretto. Di solito non sai nemmeno tutto ciò che è stato fuso perché sono comunque tutte le modifiche degli altri.

L'unica volta che suggerirei di essere più prolisso sarebbe quando si lavora con più di un repository. Se si dispone di un repository di sviluppo e di un repository stabile, e si stanno ottenendo correzioni di bug da stable, vorrei solo menzionarlo nella fusione: "merging with stable". Queste fusioni tendono ad essere più grandi, quindi aiuta a spiegarle alle persone che verranno dopo.

Answer 5

È possibile raccogliere tutti i gruppi di modifiche appena aggiunti commettere messaggi in un file da

$ hg log --rev 'reverse(p2():ancestor(p1(),p2())-ancestor(p1(),p2()))' \ 
     --template '{desc}\n' \ 
     > commit-message.txt 

quindi modificare manualmente commit-message.txt, e, infine, usarlo come il messaggio di registro:

$ hg commit -l commit-message.txt 

Answer 6

Fintanto che "merg" è nel messaggio in qualche modo, ci siamo divertiti a sfruttare l'opportunità di riempire i nostri registri mercuriali con ilarità. Ad esempio, abbiamo utilizzato messaggi di fusione come "i prestiti di fusione immobiliare sono a un minimo storico" o "una produzione televisiva Merge Griffin".