Controllo Di Versione - Git Mercurial

Volevo iniziare ad utilizzare un programma per il controllo di versione…

Mi sono scaricato Git e Mercurial per provarli… Li utilizzo con le GUI e non da riga di comando.

Con Git sto usando Source tree

Con mercurial invece uso Tortoise Hg

Ho provato a fare qualche prova… ovviamente non ci capisco un tubo…

Qualcuno può aiutarmi ad entrare in questo mondo del controllo versione?

Ho letto molte guide in rete… ma nessuna nello specifico del caso "sito web".

Ho provato con WAMP a creare un nuovo progetto e poi usare Git e mercurial per vedere come fare… ma mi sono perso…

Il fatto è che mi trovo nel ramo master… faccio la modifica al file… ma la modifica giustamente appare subito nel sito…

Da quello che ho capito è utile nel caso di nuove features per il sito… per esempio voglio fare un nuovo login… però prima lo voglio testare e non metterlo subito nel sito online… quando è tutto ok lo voglio rendere accessibile anche nel sito online…

Forse ho un pò di confusione in testa… qualcuno mi può fare un po di chiarezza?

Grazie

devi fare un nuovo branch e poi quando è tutto testato fai un merge su master.

ma che ide usi per sviluppare? potresti usare un plugin che ti aiuta nella gestione e non strumenti separati.

principalmente uso dreamweaver ma anche netbeans

Ti suggerisco di leggere questa guida: http://git-scm.com/book/it/Per-Iniziare-Basi-di-Git.

PS. Git si comporta allo stesso modo sia che tu abbia a che fare con immagini, files, documenti, interi siti, singoli file, …

dreamweaver non lo utilizzo, ma ho usato netbeans con plugin e uso eclipse con plugin ;)

bene ho preso mano con git (uso la GUI sourcetree).

E’ davvero molto bello è utile!!!

Un’altra domanda…

Avete presente che tipo nelle estensioni di yii o più comunemente in qualsiasi programma per pc c’è il numero di versione?

Che viene incrementato o di 1 per una major release o di 0.1 per un bugfix?

Ecco volevo sapere… ma quella cosa la viene fatta a mano o c’è modo con git di farlo in automatico?

E’ tutto fatto a mano e puoi anche inventarti il workflow che preferisci. Diciamo, però, che c’è una sorta di standard de facto. Non ne sono esperto ma potresti seguire queste regole:

X.Y.Z è la versione del tuo software.

Quando riscrivi il codice da zero (from scratch) incrementi la X.

Quando togli feature e/o perdi retrocompatibilità incrementi la Y.

Quando ottimizzi, fai refactoring, risolvi bug, … incrementi la Z.

Ubuntu funziona in maniera diversa: Y.M. In Ubuntu ll valore a sinistra del punto indica l’anno mentre quello a destra è il mese. In oltre Ubuntu viene rilasciato ad aprile e ad ottobre. In questo momento l’ultima versione è 13.04 (siamo nel 2013 ed aprile è passato). La prossima sarà 13.10, … nel prossimo anno avremo 14.04 e 14.10 e così via.

Altri software ragionano in questo modo. La X indica la versione del codice (totale riscrittura). Il secondo valore se pari indica che la versione non è ancora stabile, se dispari indica che si tratta di una versione stabile. Facciamo un esempio.

2.0 hai appena riscritto un nuovo software

2.0.1 hai risolto bug e stabilizzato il codice

2.0.2 hai risolto bug e stabilizzato il codice

2.1 hai rilasciato un software stabile

2.2.1 hai risolto bug e stabilizzato il codice

2.2.2 hai risolto bug e stabilizzato il codice

In pratica ci sono periodi in cui si aggiungono feature, ed altri in cui si stabilizza il software. Potresti leggere questa pagina che indica la roadmap di Symfony2. Yii, per esempio, in questo momento sta preparando la sua 2.0. In questo momento è disponibile una 2.0 Public Preview (siamo ancora prima della Alfa).

Io, in genere seguo poche semplice regole.

Parto dalla 0.1 (butto su un po’ di codice) che va.

Aspetto e se non ci sono bug sono contento. Se ci sono bug passo alla 0.1.Z incrementando ad ogni rilascio.

Se aggiungo feature, allora passo alla 0.2 e ripeto il giochino. 0.2 e poi 0.2.x.

Poi un bel giorno decido di riscrivere tutto e rilascio la 1.0

A dire il vero, … siccome non mi piace partire da 0, è facile che preferisca la versione 1.0 come versione di partenza.

L’importante, qualsiasi sia la strada che deciderai prendere, è definire uno standard più o meno dettagliato e magari scriverlo nel readme del tuo programma.

ah ok. Sei stato chiarissimo! Grazie mille!