Probabilmente hai familiarità con strumenti come Git e Subversion. Ma, come web designer, è del tutto possibile che, sebbene si possa dire che si usi il controllo della versione nei propri progetti, la verità è che, molto spesso, semplicemente non si. Se si adatta questa descrizione, non preoccuparti; non sei solo. In realtà, è l'opinione di questo autore completamente non criticata che la stragrande maggioranza dei web designer non lo fa! Il dilemma è che c'è una credenza comune che il controllo della versione sia rigorosamente per i programmatori hardcore, che trascorrono i loro giorni nell'oscurità, e che raramente escono in aria, tranne quando il microonde emette un segnale, segnalando che la tasca calda è pronta per essere mangiata.
In realtà, se si esegue la codifica per il Web, sia sul front-end che sul back-end, è necessario eseguire il codice in modo responsabile: utilizzare il controllo della versione.
5 segni che sei in ritardo per il controllo della versione
Non hai idea di cosa sia il controllo della versione, o perché potrebbe essere utile.
Codice locale e nessun sistema di backup.
Esegui il backup dei tuoi progetti duplicando sporadicamente la directory principale.
Hai accidentalmente cancellato un file in modo permanente e hai dovuto ricodificare da zero.
Dopo aver apportato una serie di modifiche, l'applicazione si interrompe, a quel punto devi tenere premuto Comando + Z per un numero doloroso di secondi, mentre guardi l'editor invertire le tue modifiche.
Ammettilo: ogni sviluppatore ha identificato con uno dei segni annotati in precedenza in un punto o nell'altro nella sua carriera. Ma ricorda: il primo passo per il recupero è ammettere di avere un problema!
5 Vantaggi immediati del controllo della versione
Cancellato accidentalmente quella classe o PSD? Esegui un singolo comando nel terminale per ripristinare uno stato precedente nel progetto. Disastro evitato!
Sei mai rimasto a bocca aperta per l'orrore, come il tuo sito web in qualche modo sparito dal tuo desktop? Era lì ieri, ma oggi è sparito! Un servizio gratuito, chiamato GitHub, rende questo un non-problema.
Chi diavolo vorrebbe scrivere questo pezzetto di codice che ora devo passare ore a riscrivere? Non c'è bisogno di chiedersi chi è la colpa; Git te lo dirà!
Codice con abbandono, pur sapendo che, con ogni commit, vengono "salvati" gli snapshot dell'applicazione, nel caso in cui sia necessario tornare a questo stato in un momento futuro.
Se per nessun altro motivo, accetta che gli sviluppatori che sono probabilmente molto più esperti di quanto tu abbia ritenuto una best practice. È utile imitare quelli a cui ammettiamo.
Idiota?
Git è il sistema di controllo delle versioni più popolare disponibile.
Quindi, come fa Git a prendere in considerazione tutto questo controllo di versione? Bene, la definizione super nerd è che Git è un sistema di controllo della versione distribuito, sviluppato da Linus Torvalds, in cui ogni directory di lavoro è il suo repository con la cronologia completa disponibile in qualsiasi momento. Inoltre, Git offre la possibilità di condividere codice e creare più rami (o timeline) per i tuoi progetti, rendendolo particolarmente adatto per i team di sviluppo agili.
Una definizione più comprensibile potrebbe essere: Git è uno strumento da riga di comando che tu - e tutti gli altri sviluppatori del tuo team - usi per salvare frequenti snapshot dei tuoi progetti. In qualsiasi momento, offre la flessibilità di ripristinare le modifiche agli stati precedenti, con un solo comando.
Il libro di Scott Chacon, 'Pro Git,' è disponibile nella sua interezza sul sito Web Git.
Installare Git
Certamente, il primo passo verso il recupero senza scrupoli di "Cowboy Coding" è scaricare Git da git-scm.com. Utilizzare uno dei seguenti URL, a seconda del sistema operativo prescelto.
Mac: http://git-scm.com/download/mac
finestre: http://git-scm.com/download/win
Successivamente, dobbiamo configurare l'installazione con un semplice tocco, associando un nome utente e un indirizzo email. Apri la tua console più vicina (Terminale su Mac) ed esegui:
$ git config --global user.name "Il tuo nome" $ git config --global user.email [email protected]
Non preoccuparti; questo deve essere digitato solo una volta, dopo aver installato Git per la prima volta. Ora, per ogni azione che fai, Git utilizzerà queste impostazioni.
Ci sono ulteriori opzioni di configurazione, come specificare quale editor di codice dovrebbe essere usato, quando Git ti richiede di digitare un messaggio di commit, ma ignora che per ora.
Congratulazioni, Git è stato installato con successo!
Il ciclo di base
Come con qualsiasi nuova tecnologia, c'è bisogno di un po 'di apprendimento.
Uno degli aspetti più difficili dell'apprendimento di Git è la decifrazione di ciò a cui si riferisce il vari gergo. Commette? Messa in scena? Filiali? Log? huh?
Come con qualsiasi nuova tecnologia, c'è bisogno di un po 'di apprendimento. Fortunatamente, per quanto Git possa essere complesso, in particolare come web designer, scoprirai che una manciata di comandi farà molto. Per fare un confronto, considera il dizionario inglese e quindi il numero di parole che utilizziamo realisticamente nelle conversazioni di tutti i giorni. Lo stesso vale per Git - ad un livello molto più basso. Quindi non sentirti sopraffatto. Prendi un comando alla volta.
Per eliminare questa terminologia confusa, è meglio pensare prima in termini di qualcosa di tangibile nel mondo reale: un camion per le consegne.
Immagina di aver iniziato un nuovo sito web statico. Hai creato cartelle per file JavaScript e CSS, nonché un file index.html con un po 'di codice HTML. In effetti, fai quella cosa proprio ora! Al termine, è il momento di creare il primo commit.
Ritorna al terminale e digita:
git init
Questo comando, "inizializza Git," informa Git che desideriamo il controllo della versione per questo progetto. Oppure, "avvia l'accensione". Ha bisogno solo di essere eseguito una volta, all'inizio del ciclo di vita di un nuovo progetto.
Quindi, determiniamo quale sia lo "stato".
stato git
Se stai lavorando, probabilmente vedrai qualcosa sulla falsariga di:
# Sul master del ramo # # commit iniziale # # file non tracciati: # (usa "git add ... "da includere in quello che sarà impegnato) # # index.html nulla aggiunto al commit ma file non tracciati presenti (usa" git add "per tracciare)
Anche se un po 'di confusione, se prendiamo un momento, vedremo che, per impostazione predefinita, stiamo lavorando su un "ramo", chiamato "master". Successivamente, abbiamo un file non tracciato: index.html. Da questo, siamo in grado di decifrare che Git non è magico; bisogna dire quali file tenere d'occhio, per così dire.
Curioso il motivo per cui le directory JavaScript e CSS non sono incluse nell'elenco dei file non tracciati? Git tiene traccia dei file, non delle cartelle. Una tecnica comune, tuttavia, per includere directory vuote in un commit è aggiungere un file .gitignore a ciascuna sottodirectory. Maggiori informazioni in seguito!
Tracciamento dei file
Per rintracciare i file, dobbiamo prima aggiungerli all'area di staging, oppure, metterli sul camion.
git aggiungi index.html
Ora, se ricontrolliamo lo stato, vedremo:
On branch master # # Initial commit # # Modifiche da eseguire: # (utilizzare "git rm --cached ... "per non rilasciare) # # nuovo file: index.html
Eccellente; Git sta guardando questo file per le modifiche. In questo caso, abbiamo aggiunto solo un singolo file. Se, invece, preferiremmo aggiungere tutti i file all'area di staging, possiamo usare il simbolo del periodo.
aggiungi git .
Tieni presente che il camion non è ancora partito; abbiamo semplicemente caricato un paio di scatole (o file) nella parte posteriore. Per eseguire l'istantanea e salvare una copia del progetto nello stato attualmente monitorato, è necessario eseguire un commit.
git commit -m 'Primo commit'
In alto, abbiamo creato un nuovo commit e fornito un messaggio di "Primo commit". Con ciò, il nostro primo impegno è stato completato e il camion è partito per la fabbrica, con una copia del progetto nella parte posteriore.
Per verificare il tuo lavoro, usa un nuovo comando: "log".
git log commit 02c934fcaf3de7677273b74d8ad3ed5041066986 Autore: Jeffrey Way Data: mercoledì 19 dicembre 15:07:23 2012 -0500 Primo impegno
Perfetto, è stato creato un nuovo commit, e sembra anche che il commit abbia un ID di riferimento univoco. Archivialo per ora.
Se tu, ancora, controlla lo stato.
stato git
Poiché non sono state apportate modifiche dall'ultimo commit, Git ci dice quanto segue:
# Sul ramo master nulla da commettere (directory di lavoro pulita)
Successo! Il 90% dell'utilizzo di Git seguirà questo ciclo.
Fare cambiamenti
Aggiungi file all'area di sosta
Esegui un commit con un messaggio che descrive l'azione che ha avuto luogo
Risciacqua e ripeti!
Passiamo al prossimo passo. Come semplice esempio, forse vogliamo includere un semplice foglio di stile di reset nel nostro progetto. Scriveremo i più elementari (forse sconsiderati) dei reset.
/ * css / reset.css * / * margin: 0; padding: 0;
Ora, torna a index.html e includi un riferimento a questo file:
Come regola di base, se riesci a descrivere alla persona seduta accanto a te quale modifica hai apportato a un progetto, probabilmente merita un commit. Impegnati spesso. Facciamolo ora; di nuovo al Terminale!
aggiungi git. git commit -m 'Aggiungi e includi ripristina foglio di stile.'
Quando si scrivono messaggi di commit, generalmente è considerata la migliore pratica per scrivere al tempo presente. Quindi, "aggiungi file" invece di "file aggiunto".
Avanti veloce a domani, e ora il tuo capo ti dice che non vogliono usare il tuo semplice file di reset. Invece, preferirebbero usare il popolare foglio di stile Normalize, di Nicolas Gallagher.
Nessun problema; con Git, questa è una soluzione semplice. Riportiamo il commit precedente e apporta le modifiche necessarie.
git revert HEAD
Con Git, la regola è "non riscrivere mai la cronologia".
Questo comando annullerà tutte le modifiche apportate al commit più recente. Essenzialmente, è un commit che fa esattamente l'opposto di quello che ha fatto il precedente. Perché ripristinare, invece di annullare completamente il commit? Di nuovo, perché stiamo seguendo le migliori pratiche. Con Git, la regola è "non riscrivere mai la cronologia". Ripristina le modifiche, ma non cancellarle e annullarle.
Dopo aver premuto Invio, verrai indirizzato a una nuova schermata con il testo, "Ripristina" Aggiungi e includi ripristina foglio di stile. " A questo punto, sei in modalità Vi (anche se sei libero di configurare Git per usare qualsiasi editor di codice che desideri.) Per ora, vai con i valori di default, salva ed esci. Esegui ciò digitando: wq (Write and Quit).
E con questo singolo comando, le modifiche sono state ripristinate. Vai avanti e controlla per essere sicuro. Il file style.css è stato rimosso e non esiste più un riferimento al foglio di stile in index.html. Questo è il potere di Git! Perché abbiamo adottato uno stile di sviluppo di commit spesso, quando collocato in situazioni, in cui è necessario invertire le modifiche, richiede solo un singolo comando. Non più pressante Comando-Z per l'enternità!
Seguendo la richiesta del capo, aggiorniamo il progetto per utilizzare Normalize.css, che abbiamo scaricato e inserito in css / normalize.css.
All'interno di index.html, fai riferimento a:
E, infine, commettiamo i cambiamenti.
aggiungi git. git commit -m "Include Normalize in project"
Sebbene questo sia stato certamente un semplice esempio, immagina quanto sia utile questa tecnica per modifiche più grandi, che si estendono su più file all'interno dell'applicazione. Raggruppando tutte le modifiche correlate in un singolo commit, otteniamo la massima flessibilità e sicurezza.
Stanza per sperimentare
Sei mai stato a un punto in un progetto, quando vuoi sperimentare un'idea che può o non può far parte dell'applicazione finita? Anche se è vero che puoi sempre annullare il commit se le cose non vanno secondo i piani, è un'idea più intelligente, per una serie di motivi, utilizzare invece la ramificazione.
Il modo migliore per illustrare il concetto dei rami Git è fare riferimento a Ritorno al futuro 2.
Su questa nota, se sei uno sviluppatore nerd e non hai guardato la trilogia di Ritorno al Futuro, ferma ciò che stai facendo e guardali!
Continuando, ricorda la parte in Ritorno al futuro 2, dopo che Marty e Doc torneranno nel 1985 dal futuro, ma scopriranno che tutto è diverso? Dopo essersi incontrato al laboratorio di Doc, ora distrutto, Doc disegna un diagramma, descrivendo come, ad un certo punto, "la linea del tempo si è incurvata in questa tangente, creando un 1985 alternativo". Questo è proprio come ramificazioni!
Considera il nostro attuale progetto dimostrativo; al momento, c'è una linea temporale: una linea retta. Non appena creiamo una filiale per lavorare sulla nostra idea, ci allontaniamo da questa linea temporale e ne creiamo un'altra. A questo punto, esistono entrambe le linee temporali e possono contenere i rispettivi commit, senza interferire l'uno con l'altro.
Come è utile? Considera un ciclo di sviluppo agile, in cui tu o il tuo team distribuite gli aggiornamenti più volte ogni settimana. Se segui l'approccio "single timeline", l'implementazione, ad esempio, di una semplice correzione degli errori di battitura, non sarebbe possibile fino a quando non hai finito di lavorare sulla tua idea. Con la ramificazione, tuttavia, abbiamo la flessibilità di impiegare tutto il tempo necessario per la nostra idea, pur continuando a liberare il ramo principale (quello predefinito e quello primario) per la distribuzione della correzione di errore ortografico.
Per creare un nuovo ramo, esegui:
Idea di $ git branch $ git checkout idea
In alternativa, combina questi due comandi in uno solo.
git checkout -b idea
Questo si traduce in: creare un nuovo ramo, chiamato "idea" (sostituire questo per essere più descrittivo di ciò su cui si sta lavorando, ovviamente), e passare ad esso.
Da questo momento in poi, qualsiasi modifica e commit effettuato non sarà referenziato all'interno del ramo principale. Vai avanti, provalo. Modifica index.html e apporta una piccola modifica:
La mia idea
Quindi, commetti il tuo lavoro.
git add index.html git commit -m 'Prima bozza della mia idea'
Ora abbiamo effettuato il nostro primo commit in questa nuova timeline. La nostra idea di fantasia ha ancora bisogno di lavoro, ma siamo sulla buona strada! Ma ora un cliente ha appena segnalato un errore di battitura che dobbiamo risolvere il prima possibile. Poiché utilizziamo correttamente i rami, possiamo tornare al ramo principale, correggere l'errore di battitura e distribuirlo.
git checkout master # fix typo git aggiungi index.html git commit -m 'correggi il piccolo errore' git push
Una volta che la nostra idea è finita, è ora di unirla alla sezione principale.
git checkout master git unione idea
Se tutto procede secondo i piani, il ramo delle funzionalità verrà reintegrato correttamente nel ramo principale, risolvendo la seconda timeline del 1985 alternativa!
Detto questo, ti imbatterai senza dubbio in situazioni in cui Git sembra piantare i piedi nel terreno e si rifiuta di continuare come richiesto. In questi casi, Git non è un idiota senza motivo! Molto probabilmente, il problema riguarda alcuni conflitti che devono essere risolti prima che Git possa procedere. Immagina di tentare di unire nuovamente un file nel ramo principale; l'unico problema è che, poiché il ramo è stato creato, il file è stato modificato sia nel ramo della funzione, sia nel master. In situazioni come questa, come potrebbe Git sapere quale versione del file dovrebbe prendere la precedenza, quando si uniscono i due? Non è così, e questo è ciò che chiamiamo conflitto.
Auto-merging index.html CONFLICT (contenuto): Unisci conflitto in index.html Unione automatica non riuscita; correggere i conflitti e quindi confermare il risultato.
Prima che Git possa procedere, è necessario risolvere il conflitto, modificando index.html.
Ignorare i file
Probabilmente arriverà un punto, quando si determina che è meglio non tracciare determinati tipi di file con Git. Gli esempi potrebbero includere il comune .DS_STORE (con cui gli utenti Mac avranno familiarità), creare directory e risorse compilate temporaneamente.
Abbastanza facilmente, Git, tramite un file .gitignore, ci consente di ignorare determinati tipi di file. Per fare ciò, crea un nuovo file .gitignore nella radice (ma non solo) del tuo progetto. Al suo interno, fornire un elenco di file o tipi di file da ignorare. Ecco un esempio di base:
.DS_STORE build / * .log * .sql * .exe
Codifica sociale
GitHub rende possibile la codifica sociale.
Finora, hai imparato come eseguire il commit del codice localmente. Ma come possono essere condivise queste modifiche con la tua squadra o il resto del mondo? Inserisci GitHub.
GitHub ti consente di condividere il tuo codice con il mondo. È la più grande comunità open source esistente.
Una volta che ti sei registrato per un nuovo account su github.com, dovrai seguire alcuni passaggi per generare una chiave speciale, in modo da associare il tuo computer con il tuo account GitHub. Non preoccuparti; se segui i passaggi, non dovresti avere problemi.
A questo punto, possiamo creare un nuovo repository e spingere il nostro piccolo progetto, per condividerlo con il mondo. Una volta effettuato l'accesso, fai clic sul pulsante "Nuovo repository", assegna un nome al tuo repository e fai clic su "Crea repository". Successivamente, ti verranno presentati alcuni comandi che possono essere incollati nel terminale. Poiché abbiamo già un repository esistente, abbiamo bisogno della seconda opzione:
git remote aggiungi origine https://github.com/USERNAME/project.git git push -u origine master
Questo indica a Git di aggiungere il nostro nuovo repository remoto e di chiamarlo alias "origine". Successivamente, spingiamo il ramo principale (non l'idea) al telecomando con l'alias di "origine".
Questo è tutto! Torna al browser, aggiorna la pagina e troverai il tuo nuovo repository, in attesa di essere condiviso con il resto del mondo.
Quando altri membri del tuo team desiderano apportare le modifiche che hai apportato, devono solo eseguire:
tira fuori
Questo comando inserirà gli ultimi aggiornamenti che sono stati inviati a GitHub! Oltre a condividere il codice, GitHub offre anche la possibilità di tracciare e contribuire a progetti open source popolari, nonché un tracker di problemi per bug e richieste di funzionalità. È il codice sociale al suo meglio!
Pensieri di chiusura
Anche se abbiamo solo scalfito la superficie di ciò di cui Git è capace, la verità è che, ancora una volta, per l'80% del tuo utilizzo di Git, le tecniche a cui si fa riferimento in questo articolo saranno sufficienti. Creare un ramo di funzionalità, scrivere del codice, aggiungerlo all'area di staging e impegnarlo con un messaggio. Quando sei pronto, uniscilo di nuovo nel ramo principale e implementalo! Quindi, risciacquare e ripetere!
Non dimenticarti: StackOverflow è il tuo migliore amico. Qualunque sia il problema, altri sono stati nella stessa identica situazione. Cerca lì prima.
Share
Accentsconagua
