Consigli per organizzare le modifiche al codice in GIT

Question

Consigli per organizzare le modifiche al codice in GIT

#1 da (1 voti)

0

Sto cercando un consiglio che rispecchi il mio punto di vista. Per prima cosa, spiegherò il mio punto di vista.

Il mio punto di vista

Lavoro in una grande azienda come sviluppatore C ++, stiamo usando GIT. Parlerò di come i nostri sviluppatori dovrebbero organizzare i commit del GIT. L'idea principale è che la maggior parte dei commit dovrebbe essere refactoring puro senza cambiamenti funzionali.

Il flusso di lavoro dell'implementazione di una funzione A dovrebbe avere il seguente aspetto:

Scopri se A si adatta all'architettura corrente
In caso contrario, refactor dell'architettura corrente in modo che la funzione A ora si adatti a essa
Implementa A senza intoppi, con il minimo possibile di modifiche aggiuntive

Il flusso di lavoro di correzione di un bug B dovrebbe apparire come segue:

Scopri la causa principale di B e se è ovvio e facile da correggere
In caso contrario, refactor codice corrente in modo che B sia ovvio e facile da risolvere
Correggere B senza intoppi, con il minimo possibile di modifiche aggiuntive

In entrambi i casi ci sono meno modifiche funzionali al codice possibile. Presumo che le modifiche al refactoring siano migliori dei cambiamenti di funzione poiché sono meno inclini ai bug (alcuni possono essere automatizzati), più facili da testare (nulla dovrebbe cambiare) e quindi sono più facili da recensire (richiede meno attenzione da un revisore). / p>

La situazione ideale è quando esegui vari commit di refactoring con probabilmente molte linee di codice modificate, e poi un commit su una riga che in realtà corregge il bug. Poiché le correzioni dei bug richiedono un'attenzione elevata da parte dei revisori, più brevi sono, meglio è.

Per rafforzare questa idea ti consiglio di categorizzare categoricamente ogni commit in uno dei seguenti tipi, contrassegnando esplicitamente ogni messaggio di commit con un piccolo simbolo:

(~) Contrassegna i refactoring puri
(-) Correzione bug di segni
(+) Contrassegna la nuova funzione implementata
(*) Segna le modifiche alle funzionalità esistenti, che non sono dovute a correzioni di bug
(=) Contrassegna alcune piccole modifiche (commenti, formattazione, rinomina file e variabili, ecc.)

La raccomandazione è di favorire (=) e (~), e assicurarsi che (-) e (*) siano il più piccolo possibile. Per quanto riguarda (+), beh ... a volte abbiamo solo bisogno di scrivere del codice:)

La domanda

Mi piacerebbe sentire l'opinione di altri esperti su questo approccio: è sensato? Ci sono insidie? Qualcuno ha esperienza con un modello simile? Finora ho trovato questo argomento correlato: Impegno spesso, perfeziona dopo, pubblica una volta: best practice Git , ma non del tutto pertinente. Non ricordo tali raccomandazioni nel codice completo di Macconel, e IIRC non raccomanda come organizzare le modifiche al codice.

Si noti che l'argomento non è specifico di GIT, ma poiché GIT ha strumenti eccellenti per la gestione della cronologia locale e la creazione di commit, l'argomento è strettamente legato a GIT.

git code-reviews refactoring c++

posta Mikhail 13.03.2016 - 14:17

fonte

1 risposta

Leggi altre domande sui tag git code-reviews refactoring c++

Perché alcune app Web aggiungono stringhe (casuali?) ai nomi dei cookie? Accesso ai dati dall'API privata (con credenziali di autenticazione di base) utilizzando Angular JS

score 1 · Answer 1

In both cases there are as little functional changes to the code as possible. I assume that refactoring changes are better than function changes since they are less bug-prone (some may be automated), easier to test (nothing should change at all) and thus are easier to review (requires less attention from a reviewer).

Non dovrebbero richiedere meno attenzione da parte di un revisore. Se lo fanno, questo dovrebbe dirti che non tratti tutto il tuo codice professionalmente. Controlla tutto il tuo codice con lo stesso livello di attenzione e dettagli - sarai molto meglio.

Lo abbiamo fatto anche in uno dei miei progetti precedenti ("il codice di test unitario non è importante quanto il codice di implementazione, non richiederà gli stessi standard di alta qualità;" - di conseguenza, abbiamo dovuto spendere due settimane, a metà del progetto, solo per pulire e refactoring il codice di test).

I would like to hear some others experts opinion about this approach - is this sensible?

Penso che non sia un approccio sensato: quello che stai proponendo è l'equivalente di una convenzione di denominazione del codice, perché il messaggio si impegna:

Queste regole devono essere documentate e la documentazione deve essere mantenuta, preferibilmente insieme al luogo in cui si applica la documentazione (probabilmente dovrai aggiungerlo allo stesso repository git).

Potrebbe essere molto meglio proporre un approccio basato su un tag di parole e suggerire un insieme estensibile di tag per tutti. Tendo ad usare "refactor:", "cleanup:" e "+" per aggiungere un nuovo codice: "+ flip module; + flip module unit tests". Ciò richiede ancora una documentazione separata per i tag, ma non per comprenderli a colpo d'occhio.

Dato che stai stabilendo queste regole in una società più grande, potrebbero esserci anche gruppi in cui le tue convenzioni non sono applicabili (c'è qualche team di scripting CLI nella tua azienda? probabilmente vorranno strutturare i loro commit in modo diverso). / p>

Potrebbero esserci anche commit che trattano più di un aspetto (refactoring e cleanup del codice nello stesso commit per esempio), o team che potrebbero aver bisogno di aggiungere altre categorie (qualcosa per il sistema di build, qualcosa per lavorare solo sui documenti , qualcosa per il mantenimento di librerie di terze parti nel repository git, ecc.)

Invece di specificare i tag di commit come standard, prenderei in considerazione l'utilizzo di alcune regole più generiche:

scrive commit in un tempo presente, forma imperativa
usa l'intestazione + riga vuota + formato dettagli (o non, ma in ogni caso, specifica il formato che usi)
specifica un criterio di ramificazione
consenti ai rami privati con regole diverse / personalizzate / senza regole (a condizione che siano private, non dovrebbero influenzare nessuno tranne gli autori, e dovrebbero aumentare la produttività.