[linux_var] Git

Luca Lesinigo luca a lesinigo.it
Mar 21 Feb 2017 19:10:24 CET


Il giorno 21 feb 2017, alle ore 15:37, Alessandro Lorenzi <alorenzi a alorenzi.eu> ha scritto:
>> ma perchè uno è costretto ad usarlo?
> Per evitare cose tipo questa :P
> 
> http://email.alorenzi.eu/c/eJwljkluxCAURE-Dd7aAb2OzYNHp4R4MnzYKHsKQ6fQhiVQqqV7VopyaLTguu6AcZTiBhd5IxnqjmeilEK6n07ywSfpxFAsZqY5Hwv07DFi7VTk_a6qNReaFAyPkoqn3o_AOALVgXVRrKWcmcCH80fQMZa1msMfWQkad7Erg8Ubg5jBiQcJfTp3zx5Ec4SKhb83_LGGuseRGy9eJDV-PbQt_oBa_NED4dOfN5PXXoEuq6Pga9me7vcUhhr1-vus0hPIDqX5McA
Da notare che molti dei risultati trovati sono esempi stupidi, un commit che rimuove delle password serve solo a rimuovere le password da quel commit in avanti, ma restano pur sempre presenti nella storia del repository. Per esempio:
	https://github.com/samir7575/jwt-spring-security-demo/commit/35801f7fca70d31e049485db5a8ed9780b46380b

Questi sono buoni esempi del perché chi fa cose del genere è giusto che soffra. Non si mettono mai dati di configurazione in un repository di codice / sviluppo, che siano dati sensibili come password o innocui come un ip privato sulla tua lan. Se proprio devi mettere le configurazioni sotto version control (e ci sono tantissimi casi legittimi in cui farlo!) vanno in un repo separato.

Allo stesso modo non bisognerebbe mettere artefatti derivati nei repository di sviluppo, pratica invece estremamente diffusa per esempio tra le web agency che confondono i repo di sviluppo con uno strumento di deploy e che dopo anni di programmazione php con pessime abitudini non sono in grado di comprendere che cosa si intenda per “build” e “deploy” (anche se non c’è codice da compilare in un binario nel senso classico del termine). I file css prodotti da sass e less, i javascript minificati e tanta altra roba simile sono solo alcuni dei casi che ci puoi trovare.

Tornando agli esempi stupidi di cui sopra… l’unico modo di togliere roba (es. password) dal “passato” è riscrivere la storia (es. tramite un rebase interattivo o tramite un git filter-branch o altro) e questo comporta gli stessi problemi di cui si parlava riguardo al rebase in generale (necessità di push -f, repository e storie diverse tra chi ha poi fatto un pull -f e chi no / non ancora, falso senso di sicurezza di aver fatto pulizia delle password, etc…).

--
Luca Lesinigo



Maggiori informazioni sulla lista Talking