1. 12
  1.  

  2. 2

    Già immagino le facce dei miei colleghi se un giorno dovessi proporre uno standard del genere :D

    1. 2

      Immagina invece una nuova versione di git che obbliga che la prima parola del m essaggio di commit possa essere solo una tra “fix:”, “upd:”, “add:”, “del:”, “doc:”.

      1. 2

        ci sono già dei tool che fanno un lavoro del genere sui messaggi: husky ad esempio, o commitizen

        se si usa github dovrebbe essere facile fare un hook (o usare github actions) per fare questo tipo di check

        1. 1

          sei un mostro :D

      2. 2

        Noi adottammo git-flow quasi subito, per cui la convenzione piu’ o meno l’ho sempre usata almeno nel branching, anche se a seconda del progetto e del team, ogni volta la abbiamo ri-definita per avere un accordo con tutti i membri. Cioe’ le categorie effettive sono cambiate nel tempo.

        Riguardo la deriva tendente a smettere di usare la convenzione penso che (magari sbaglio):

        • se non hai voglia di usare un tag e’ perche’ forse ci sono troppe cose sul piatto da fare e ti sembra una perdita di tempo rispetto a scrivere una scempiaggine e premere commit/push

        • non usare nessuna convenzione credo che sia comunque ancora piu’ complicato, perche’ hai uno spazio bianco da riempire e nessuna linea guida per inquadrare il lavoro fatto, una convenzione aiuta anche a superare il blocco e riduce lo spazio rimasto per spiegare nel dettaglio

        • sul semantic versioning ho delle perplessita’. Ho letto articoli che spiegavano come potessero essere fuorvianti e sentito persone che spiegavano come forniscono poco valore di business per capire di cosa si parla (suggerimento e’ stato usare versioning legato alla data, piu’ qualche incrementale). Io non ho una idea definitiva in merito

        1. 1

          La convenzione però non cambia il risultato finale secondo me 😂. Verrà seguita per x commits e poi si torna ai soliti messaggi poco “parlanti”.

          1. 2

            Infatti le convenzioni non vanno seguite ma forzate

            1. 1

              Ok…

            2. 1

              Guarda, l’abbiamo messa in campo da qualche mese e siamo tutti contenti 😎 più che altro perché aiuta tutti anche ad essere up to date con gli sviluppi

              1. 1

                Non metto in dubbio, nel gruppo in cui sono adesso secondo me dopo 1 mese mi mandano a quel paese 😂, i vantaggi a livello di team non li discuto ovviamente nell’avere dei commit organizzati come Dio comanda :D

            3. 1

              Boh, sarò strano, ma il semantic versioning l’ho sempre più o meno adottato e saranno almeno 20 anni che metto sempre messaggi di commit esplicativi. Inoltre sui vari repo mantengo un changelog.md dove di volta in volta, ad ogni push aggiungo una riga con una descrizione “di business” (ma tecnica) di quello che è cambiato in quella versione, se si introduce un’incompatibilità con la versione precedente, se si introduce una nuova funzionalità, se si corregge un bug, ecc. E se si è modificato qualcosa da far aumentare uno dei numeri del semver, lo faccio subito secondo le convenzioni del semver.

              L’idea di estrarre il changelog in automatico è ovviamente buona, ma ci vuole molta disciplina a scrivere non solo messaggi di log esplicativi e secondo le linee guida, ma anche “di business”, cioè in bella copia per un changelog consegnabile all’utente, poco interessato ai messaggi di log tecnici degli sviluppatori.

              Come lo faccio io il changelog, cioè a mano di volta in volta, ottengo un changelog più sintetico ed aggregato. Magari una singola riga che illustra una nuova feature, si traduce in 10 messaggi su altrettante commit: è meglio fare un changelog con tutti i messaggi di ogni singola commit, oppure uno che riassume in maniera chiara la modifica?

              Io propendo per quest’ultima ipotesi, per la prima c’è il comando git log.

              Comunque l’idea di fondo è sacrosanta: i messaggi di commit devono essere scritti in maniera da essere utili e bisogna stabilire degli standard da seguire, qualunque essi siano/

              Il problema è farli seguire a tutti, ma proprio tutti gli sviluppatori. Basta un solo sviluppatore che metta messaggi di commit a cavolo (es. “Modificata Classe.java”) per far saltare tutto il castello.

              1. 3

                Il problema è farli seguire a tutti, ma proprio tutti gli sviluppatori. Basta un solo sviluppatore che metta messaggi di commit a cavolo (es. “Modificata Classe.java”) per far saltare tutto il castello.

                Esatto, è quello che cercavo di sottolineare. Ben vengano convenzioni utili, il mio dubbio è puramente sulla natura umana della cosa.

                1. 3

                  come dicevo sopra, è una cosa che si potrebbe controllare. Apri PR? controlli che i messaggi siano corretti ad esempio. Insomma, con un pochino di lavoro credo si possano raggiungere degli ottimi risultati, poi ovvio, ci sarà sempre l’eccezione

                  1. 2

                    ma penso che una roba del genere si possa forzare con degli hook, no? O spaccando le pipeline se proprio non si può con gli hook

                    1. 2

                      Dite che è impensabile nominare un “tech lead” owner della repo in modo da forzare gli altri sviluppatori ad aprire PR?

                      1. 3

                        Basta proteggere master e/o develop in modo da non poter fare commit diretti su di essi se non da PR :)

                        1. 3

                          Si si. Ma quello che intendevo dire è, nel mondo reale, è fattibile una cosa del genere? Se penso ad una cosa del genere nel mio team, potremmo rimanere paralizzati per mesi

                          1. 2

                            Noi siamo un team di 15 persone e lavoriamo benissimo. In azienda tutti i team oltre al nostro usano queste stesse convenzioni con successo da anche più tempo, quindi direi di sì!

                            1. 2

                              Fantastico. Hai avuto modo di assistere al processo di adozione? Mi piacerebbe introdurlo nell’azienda in cui lavoro cavolo :)