Che è meglio per piccole correzioni di bug e piccole funzionalità - nominare i rami per numero di biglietto o nominarli per descrizione delle caratteristiche?

10

Sono nel bel mezzo di un disaccordo (cordialissimo, ovviamente) con la mia guida sulla corretta denominazione dei rami. Questo vale per le correzioni di bug e piccoli rami di funzionalità, non per rami di funzionalità di lunga durata. Per i rami delle funzionalità di lunga durata, siamo d'accordo sul fatto che i nomi leggibili dall'uomo siano migliori. Ecco i due punti di vista:

Mine:

È meglio nominare i rami in base alla loro 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 rami pertinenti in GIT quando cerchi informazioni storiche su un ticket.

Esempio:

team-name/12345
team-name/53719

La sua:

Denominazione di rami in base alla loro funzione / funzionalità. Rende più facile il completamento automatico ed è più facile da ricordare rispetto ai 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 a lui non piace, dato che mette in crisi il completamento automatico del GIT.

Se questo è principalmente basato sull'opinione, non esitare a darmi una guida su come questo possa essere più adatto per SO - ma penso che i motivi che ho dato possano essere modificati / aggiunti per dare una risposta empirica.

    
posta Codeman 06.08.2013 - 19:58
fonte

3 risposte

5

In questo caso sembra che sia possibile compromettere una convenzione di denominazione che contiene sia il numero sia la descrizione:

Esempio:

di squadra Nome / (12345) fix-che-sql-bug

di squadra Nome / (53719) -expand-http-parser

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

Ma se entrambi vi compromettete ottenete il meglio da entrambi i mondi. Cerco di tenerlo a mente quando abbiamo disaccordi simili sul mio team.

Modifica

Per affrontare il problema del completamento automatico puoi inserire l'ID numerato tra parentesi, in questo modo quando vai a digitare un ramo digiti sempre (per vedere i rami.) Da questo elenco potrai vedere l'ID numerato e la descrizione. Basta digitare un paio di numeri, scheda, e sarà

    
risposta data 06.08.2013 - 20:01
fonte
1

In realtà non importa finché esiste un sistema coerente che tutti sono d'accordo e capiscono.

Direi che se si considera il numero del biglietto, è più facile ricordare per quale ramo lavorare. Poiché si collegano direttamente al numero di rilascio piuttosto che a una descrizione. Fare solo una descrizione sembra rendere più difficile ricordare quale problema specifico dovrebbe essere e potrebbe diventare a lungo tentato di evitare di essere vago.

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

    
risposta data 06.08.2013 - 20:02
fonte
0

Dare un nome solo per sfruttare il completamento automatico è stupido.

Sono d'accordo sul fatto che un link al bug tracker è importante (più importante di un buon nome in quanto definisce esattamente il problema risolto dal ramo che un paio di parole non ha) ma allo stesso tempo, è un errore di usabilità aspettarsi che le persone sappiano la differenza tra bug # 7312 e # 7213. Inoltre non si aspetta che le persone ottengano perfettamente i numeri ogni volta - un giorno qualcuno si impegnerà nel ramo sbagliato perché ha errato / errato 7312 per 7213. (qualcuno del mio team lo ha fatto oggi!)

Quindi, fate entrambe le cose: numerate il ramo e aggiungete una descrizione del testo molto breve solo per fungere da controllo. Metterei il numero prima - il completamento automatico è dannato - dato che devi comunque conoscere il testo del ramo (ad esempio "bug-fix-per-server" o "fix-bug-per-server" - devi ancora sapere se inizia con f o b!)

    
risposta data 01.10.2013 - 11:44
fonte

Leggi altre domande sui tag