Flusso di lavoro Git per sviluppatore solitario (new git newbie)

Question

Ho deciso che è tempo per me di iniziare a utilizzare Git su un progetto PHP che ho sviluppato casualmente per oltre un decennio. (Per favore, non ci sono lezioni da parte della polizia di controllo della versione!) A causa della complessa configurazione richiesta al mio VPS per fare tutto ciò di cui ha bisogno il progetto (specialmente la struttura single-codebase-multiplo-client e l'installazione giapponese di TeX per creare PDF speciali), non è possibile impostare un ambiente di sviluppo sulla mia casella Windows locale. Ma ho un'area testbed sul server in cui posso giocare, quindi è la mia area di sviluppo. Attualmente utilizzo Filezilla per accedere al server e aprire i file direttamente in Notepad ++, e quando sono pronto per vedere la mia modifica in azione, salvo solo caricare Filezilla. Quando tutto sembra a posto sul piatto di prova, copio i file nell'area di base del codice di produzione. Sì, questo non mi dà alcuna storia dei miei cambiamenti se non i miei stessi commenti, e devo stare attento a non mescolare correzioni di bug con le nuove funzionalità a metà. Riesco a vedere il valore delle filiali di Git per diversi aggiornamenti in corso.

Ieri mi sono bagnato le dita dei piedi. Per prima cosa ho creato un account Github e poi (su consiglio di un tutorial) ho installato Git For Windows (con la sua interfaccia grafica Bash e minuscola) e Kdiff3 e ho seguito alcune istruzioni per configurare Git Bash. Dopotutto, però, ho dovuto installare qualcos'altro per interfacciarmi con il mio account Github (opportunamente chiamato Github per Windows), che sembra fare tutte le cose che gli altri due programmi avrebbero dovuto fare per me. Ad ogni modo, ho fatto un semplice compito come la mia prima incursione nel mondo di Github: avevo aggiunto funzionalità al plugin jQuery di qualcun altro e volevo condividerlo con lo sviluppatore, così ho biforcuto il suo repository, clonato nella mia macchina , ho sovrascritto il file che avevo precedentemente modificato e testato, sincronizzato nel mio account Github e ho inviato una richiesta di caricamento . Tutta la terminologia in quell'ultima frase era nuova per me, quindi ero abbastanza orgoglioso di me stesso che mi sono fatto così lontano. ;) Ma immagino di aver solo bisogno del software Github, non del software Git: è difficile sapere a quali tutorial credere.

In ogni caso, ora voglio capire un flusso di lavoro per le mie cose, che è la mia vera domanda per voi ragazzi. Da quello che posso dire, avendo il master repo ovunque, ma il pubblico Github costa denaro, e non mi interessa se gli altri vedono il mio codice (non mi aspetto che nessun altro lavori sul mio progetto oddball fatto di spaghetti code, ma se loro vogliono, è grandioso). Ok, ma allora? Forse uno di questi scenari, o qualcosa d'altro:

1. rami clone del pronti contro termine al mio PC, effettuare modifiche sui file locali, e caricarli in Filezilla per il test (un paio di clic in più rispetto al mio flusso di lavoro attuale, perché Filezilla non vede automaticamente la relazione tra il file locale e il file remoto, ma non è un grosso problema). Poi, quando sono soddisfatto del codice, eseguo il commit localmente, sincronizzo con Github e copio i file (da qualche parte - non sono sicuro su questo punto) nell'area di produzione.

2. Installare il sapore Linux di Git sul mio VPS in modo che il percorso del file Git "locale" sia il banco di prova e utilizzare Git attraverso PuTTY per eseguire i commit locali. Più semplice per la struttura del file (senza bisogno di una copia sul mio PC a tutti), ma più complesse da usare Git:

   • Io non sono su PuTTY molto frequentemente, e per qualche motivo la connessione muore spesso su di me e io riavviare.
   • Anche se la linea di comando di Linux è l'habitat nativo di Git, sono probabilmente più a mio agio con una GUI (perché dimentico rapidamente la sintassi del comando, vecchio cervello, immagino).

   Inoltre, poiché non ho mai finito di usare il programma Git che ho installato qui, non sono sicuro che sarebbe Git o Github che userei sul server.

3. Qualche altro scenario, dal momento che né # 1 né # 2 utilizzano Git/Github per gestire l'area del file di produzione, il che probabilmente sarebbe una buona idea in modo che non dimentichi di copiare tutto ciò di cui ho bisogno.

ho cercato di ricerca la possibilità di una GUI basata su PHP per andare con l'idea # 2 (quindi non c'è bisogno di usare mastice per le operazioni giorno per giorno), ma sembra che le discussioni di tali strumenti tutti presuppongono che si stia tentando di creare il proprio servizio Github, o che il repository clonato "locale" sia fisicamente sul PC locale (con xAMP in esecuzione su qualunque sistema operativo sia). Ma forse il software Github che ho usato è sufficiente per fare tutto questo, è difficile da dire. Non ho ancora capito l'interazione tra un master repo pubblico su Github, filiali da qualche parte (su Github anche?), Almeno due set di file sul mio server web (il banco di prova e l'area di produzione), software Github, software Git, e la tastiera/lo schermo del computer in cui sono seduto.

Quindi perdona le mie parolacce ai novizi, ma se qualcuno là fuori ha una situazione di sviluppo simile, qual è il tuo flusso di lavoro? O cosa suggeriresti per me?

Answer 1

Ecco un modo per aproach il problema:

Avrete bisogno di tre archivi:

• un pronti contro termine locale per modificare il codice. [1]
• un repository remoto nullo sul server. Questo si troverà in una posizione che non è visibile pubblicamente, ma puoi farlo. [2]
• L'ambiente di produzione. [3]

Ecco l'implementazione:

workstation$ cd localWorkingDirectory/ 
workstation$ git init 
workstation$ git add . 
workstation$ git commit -m 'initial commit' 
workstation$ ssh login@myserver 
myserver$ mkdir myrepo.git 
myserver$ cd myrepo.git 
myserver$ git init --bare 
myserver$ exit 
workstation$ cd localWorkingDirectory/ 
workstation$ git remote add origin login@myserver:myrepo.git 
workstation$ git push origin master 

ogni volta che si effettua un commit su ogni ramo, eseguire il backup con:

workstation$ git push origin BRANCH 

Quando si è pronti a muoversi ramo version2 in produzione: fare questo

workstation$ git push origin version2 
workstation$ ssh login@myserver 
myserver$ git clone path/to/myrepo.git productionDirectory 
myserver$ cd productionDirectory 
myserver$ git checkout version2 

Oh no! Non funziona! meglio tornare alla versione 1!

workstation$ ssh login@myserver 
myserver$ cd productionDirectory 
myserver$ git checkout version1 

Answer 2

Cercherò sicuramente qualcosa come capistrano per la configurazione di sviluppo corrente.

Posso capire perché potresti avere una reticenza nell'usare il terminale ma probabilmente ti aiuterà a capire la tua git nel contesto. Non ci vuole molto a fare i conti con i comandi e quando legato in un sistema come Capistrano ti verrà a dondolo codice di sviluppo fino al vostro ambiente in poco tempo:

git commit -a 
git push origin develop 
cap deploy:dev 

quando sto lavorando su Windows In genere provo a replicare l'ambiente di distribuzione che ho con le macchine virtuali localmente usando qualcosa come la virtualbox di sun. In questo modo puoi ridurre al minimo i potenziali problemi ambientali mentre si sviluppa ancora localmente. Quindi puoi semplicemente usare putty in ssh nel tuo vm locale. Funzionerà anche la condivisione dell'installazione tra VM e il tuo SO host e tutti i tuoi IDE/editor standard. Trovo che sia preferibile dover configurare un VPS da remoto ma qualunque cosa funzioni.

Answer 3

Non è necessario github (o qualsiasi altro archivio centrale) per iniziare a utilizzare git. Soprattutto perché sei uno sviluppatore solitario. Git viene eseguito direttamente sul tuo computer, senza alcun componente del server (a differenza, ad esempio, di subversion). Basta git init e inizia a commettere via.

Sono d'accordo con gli altri commentatori qui, che si dovrebbe mirare a ottenere un ambiente di sviluppo locale attivo e funzionante. Anche se ci vuole un po 'di sforzo, ne vale sicuramente la pena. Uno degli effetti collaterali di ciò potrebbe essere il fatto che sei costretto a disaccoppiare alcune delle tue attuali e difficili dipendenze, ottenendo così una migliore architettura generale delle applicazioni. Le cose che non possono essere facilmente replicate nel proprio ambiente di sviluppo potrebbero invece essere sostituite con servizi di simulazione.

Una volta installato, esaminare un processo di distribuzione basato su script. Per esempio. scrivere uno script di shell che sincronizzi il codebase della macchina di sviluppo con il server di produzione. Ci sono molti modi per farlo, ma ti suggerisco di iniziare in modo molto semplice, quindi rivedere le opzioni (Capistrano è un'opzione).