Qual è la soluzione migliore per piccole correzioni di bug e piccole funzionalità: denominare i rami in base al numero del biglietto o denominarli in base alla descrizione della funzione?

10

Sono nel mezzo di un disaccordo (cordiale, ovviamente) con la mia guida su una corretta denominazione dei rami. Questo vale per la correzione di bug e piccoli rami di funzionalità, non rami di caratteristiche di lunga durata. Per i rami delle funzionalità di lunga durata, concordiamo che i nomi leggibili dall'uomo sono migliori. Ecco i due punti di vista:

Il mio:

È meglio nominare le filiali in base alla squadra e al numero del biglietto. Rende più facile trovarli nel nostro sistema di ticketing e più brevi da digitare. Inoltre semplifica la ricerca di filiali pertinenti in GIT quando si cercano informazioni storiche su un biglietto.

Esempio:

team-name/12345
team-name/53719

Il suo:

Denominare i rami in base alla loro caratteristica / funzionalità. Semplifica il completamento automatico ed è più facile da ricordare dei singoli numeri.

Esempio:

team-name/fix-that-sql-bug
team-name/expand-http-parser

Un compromesso che ho offerto è questo:

team-name/12345-fix-that-sql-bug

Ma non gli piace questo, poiché fa casino con il completamento automatico GIT.

Se questo è principalmente basato sull'opinione, sentitevi liberi di darmi una guida su come ciò possa adattarsi meglio alla SO - ma penso che i motivi che ho dato possano essere modificati / aggiunti per dare una risposta empirica.

— Codeman
fonte

nella mia esperienza, la migliore denominazione per i rami per piccole correzioni di bug e piccole funzionalità era spesso tronco (unire in anticipo, unire spesso => non è necessario isolare le modifiche senza una giustificazione sufficiente). Questo ovviamente non si applica alle correzioni critiche di back-porting alle versioni precedenti del codice in esecuzione in produzione, per le quali l'isolamento è giustificato più che sufficiente (e per il quale, a sua volta, è naturale nominare i rami dopo i ticket: dopo tutto, non stai facendo nulla di particolarmente significativo come caratteristica, stai semplicemente risolvendo un bug di produzione critico concreto con un biglietto concreto)

— moscerino

5

In questo caso sembra che sia possibile scendere a compromessi su una convenzione di denominazione che ha sia il numero che la descrizione:

Esempio:

squadra-name / (12345) fix-che-sql-bug

squadra-name / (53719) -expand-http-parser

Non c'è davvero una risposta corretta qui, è soggettiva a seconda del tuo punto di vista.

Ma se entrambi scendete a compromessi, otterrete il meglio da entrambi i mondi. Cerco di tenerlo presente quando abbiamo disaccordi simili nella mia squadra.

Modificare:

Per affrontare il problema del completamento automatico puoi mettere l'id numerato tra parentesi, in questo modo quando vai a digitare un ramo digiti sempre (per vedere i rami. Da questo elenco sarai in grado di vedere l'id numerato e la descrizione. Digita semplicemente un paio di numeri, tab e lo farà

— dmck
fonte

Sono d'accordo, e l'ho aggiunto: penso che sia sciocco non essere d'accordo con questo compromesso.

— Codeman,

Il completamento automatico funziona solo dall'inizio del nome del ramo? puoi mettere l'ID alla fine? Non utilizzo la funzionalità di completamento automatico, quindi non ho familiarità con esso.

— dmck,

sì, funziona dall'inizio alla fine - se vuoi ottenere team-name/12345-my-ticket-fixdevi digitare team-name/123TAB, essenzialmente.

— Codeman,

@ Pheonixblade9 Vedi la mia modifica per una possibile soluzione, inserendo un (prima che l'ID ti impedisca di dover conoscere l'ID quando si digita il nome del ramo

— dmck

1

Non importa davvero fino a quando esiste un sistema coerente che tutti sono d'accordo e capiscono.

Direi però che andare in base al numero del biglietto manterrebbe le cose più facili da ricordare per quale filiale lavorare. Poiché si collegano direttamente al numero di emissione anziché a una descrizione. Fare solo una descrizione sembra rendere più difficile ricordare quale specifico problema dovrebbe essere e potrebbe essere prolisso cercando di evitare di essere vago.

team-name/bug-that-has-specific-circumstances-to-occur-and-takes-alot-to-describe

— Clusio
fonte

0

È stupido nominare qualcosa unicamente per sfruttare il completamento automatico.

Sono d'accordo sul fatto che un link al bug tracker sia importante (più importante di un buon nome in quanto definisce esattamente il problema risolto dal ramo che un paio di parole non lo fanno) ma allo stesso tempo, è un errore di usabilità che non ci si aspetta dalle persone per conoscere la differenza tra bug # 7312 e # 7213. Inoltre, è un errore aspettarsi che le persone ottengano sempre i numeri perfettamente giusti - un giorno qualcuno si impegnerà nel ramo sbagliato perché hanno letto male / digitato 7312 per 7213. (qualcuno della mia squadra l'ha fatto oggi!)

Quindi fai entrambe le cose: numera il ramo e aggiungi una breve descrizione del testo solo per fare da segno di spunta. Vorrei prima inserire il numero - il completamento automatico deve essere dannato - poiché devi comunque conoscere il testo del ramo (ad esempio "bug-fix-for-server" o "fix-bug-for-server" - devi ancora sapere se inizia con f o b!)

— gbjbaanb
fonte