Ho un contratto per scrivere parte di un programma. La persona che scrive l'altra parte si trova in un'altra città. Voglio trovare un modo conveniente per inviare modifiche avanti e indietro. Per altri motivi, mi piacerebbe imparare a usare git come VCS distribuito e le e-mail cambiano avanti e indietro. (Ho lavorato prima con SCCS, RCS e PVCS, sempre con il blocco. Voglio spingermi a imparare come utilizzare meglio la fusione & e non dipendere da un server centrale.)
Abbiamo bisogno di fare il Seguendo due compiti (elenco piuttosto standard):
(a) Ognuno di noi contribuisce alle correzioni di bug e alle nuove funzionalità che richiedono modifiche a entrambe le parti.
(b) Compilare e impacchettare i binari per i clienti.
(Dobbiamo anche lavorare separatamente su funzionalità che non dipendono dall'altra, ma presumo che tutto ciò che funziona per l'attività (a) funzioni anche per questo.)
Sfondo: L'altro ragazzo non ha mai usato un VCS prima; è un po 'resistente all'idea. Non sapeva nemmeno che non usano ancora i controlli di chiusura. Dovrei capire tutto ciò che facciamo in modo abbastanza approfondito da poterlo aiutare nei momenti difficili con non molta frustrazione da parte sua. È anche molto a disagio con la memorizzazione della fonte su un server, che è un altro motivo per preferire le modifiche alle e-mail. Possiamo facilmente crittografarli.
Altro contesto pertinente: Usiamo Delphi su Windows come ambiente di sviluppo. È estremamente improbabile che aggiungeremo un altro sviluppatore. Abbiamo solo bisogno di impacchettare le versioni dei clienti un paio di volte all'anno, se così fosse. Il numero di clienti probabilmente non supererà mai i dieci.
Domande:
1) Devo utilizzare questo progetto per apprendere le tecniche per lo sviluppo distribuito? O è così esagerato che dovrei semplicemente fare qualcosa di più semplice? Non mi importa passare un po 'di tempo in più sull'apprendimento, ma non più di un paio di settimane.
2) Assumendo "Sì" alla domanda 1, quale flusso di lavoro dovremmo utilizzare per ciascuna delle attività di cui sopra?
3) Quali programmi dell'interfaccia grafica di Windows eseguiranno tutte le attività richieste? (Sono molto a mio agio con la roba da riga di comando, non lo è.)
Grazie per il vostro aiuto.
Ho scritto un tutorial molto dettagliato su "gitting started" che mostra ciò che ho imparato finora sull'uso di git. È a http://xorandor.com/GittingStarted se vuoi leggerlo finora. Ho provato a scriverlo per un novizio git che ne sa un po ', ma non molto sui VCS in generale. Ho in programma di aggiungere a questo mentre imparo di più.Quale flusso di lavoro git utilizzare per 2 sviluppatori non collocati nella stessa posizione?
risposta
L'altro utente non ha mai utilizzato un VCS prima; è un po 'resistente all'idea di .
Sono stato coinvolto nell'addestramento e nel supporto degli utenti che sono stati costretti a passare da fonte-sicurezza a sovversione. C'è stata una quantità sorprendente di resistenza dell'utente. È passato più di un anno e continuo ad essere chiamato per sistemare le cose quando "sovversione ha rotto il mio materiale" (non è mai il caso, ovviamente).
Conoscendo questo, sarei molto titubante nel cercare di aiutare qualcuno a passare da nessun VCS a Git (che probabilmente non è il VCS più user-friendly in circolazione). Soprattutto se odiano l'idea di un VCS. Detto così se non puoi essere lì ad aiutarli alla loro scrivania.
Considerare quindi: alcune cause sono solo cause perse. A meno che non si lavori con questa persona per un lungo periodo, potrebbe essere meglio impostare un repository solo per te stesso. Puoi lasciarglielo e-mail con i file modificati e viceversa. Almeno git ti renderà più facile vedere quali file sono stati modificati dall'ultimo punto di integrazione.
Si dovrebbe utilizzare questo progetto per imparare git? Direi di si.
Oltre allo inherent benefits of source control, l'utilizzo di git ha il vantaggio di avere copie complete del repository su ogni sistema di sviluppo.
Una cosa che vorrei fare sopra ad avere un repository, è che ognuno di voi si sincronizzi con un server centrale ogni giorno o così.
Il flusso di lavoro sarebbe andato come:
- si apportano modifiche al repository git locale come spesso possibile.
- A intervalli fissi (una volta al giorno, dopo una correzione o una funzionalità di un grosso errore, ecc.), Spostare il repository su un repository centrale situato sul proprio host Web o altro provider di hosting git (ovvero, GitHub).
- Estrarre sempre le modifiche dal repository centrale anziché dagli altri repository. È possibile trattare il repository centrale come repository di release e ciò eviterà la confusione su quale repository (il proprio o suo) sia il più aggiornato.
So che l'intero punto di un sistema di controllo della versione distribuita è di non avere un repository centrale, ma mi piace davvero avere quella copia extra fuori sede. Se c'è qualcosa ti dà ancora un'altra copia del repository a scopo di backup.
Per quanto riguarda git su Windows, vorrei controllare il illustrated guide to running git on windows. Il git-gui integrato lascia molto a desiderare, ma è funzionale e utilizzabile.
Inoltre, poiché il tuo partner è nuovo al controllo del codice sorgente, ti consiglio l'eccellente Source Control HOWTO di Eric Sink. Ti dà un sacco di ottime informazioni su come di controllo del codice sorgente.
Sono abbastanza nuovo in git, ma forse il modo più veloce per iniziare è questo:
Con git puoi creare due repository sul tuo computer.
Uno per il tuo lavoro e in secondo luogo per il lavoro che ti invia.
Ci nice tutorial to start (come detto da Nick)
Questo strumento è un bene se si lavora con le finestre/eversione prima TortoiseGit
Il mio punto: non iniziare a insegnargli finché non si sente molto bene in git, fare una sia repos/branches nel tuo computer.
Mi piacerebbe solo configurare autosetuprebase su ciascuno e iniziare con una semplice installazione.
Abbraccia i conflitti che ottieni - quelli sono i cambiamenti che altrimenti sarebbero andati perduti.
Nella mia esperienza, Git non è ancora supportato su Windows.
Per un DVCS simile ma IMHO più user-friendly, vedere Mercurial (a.k.a. Hg). Ha un client Tortoise e uno strumento da riga di comando piuttosto amichevole.
Esistono anche plug-in di Visual Studio ed Eclipse per Mercurial (credo che anche NetBeans). Funzionano abbastanza bene e sono una grande aggiunta agli altri strumenti. (Stuff get aggiunto/eliminato/rinominato automaticamente e le attività di sincronizzazione di base (push/pull) funzionano correttamente.)
hai sentito parlare di tortioise-git? – Avram
Sì, ma quando l'ho guardato (novembre 2008) non era quasi completo come la variante di hg. Inoltre, lo sviluppatore principale era un po 'turbato dalla mancanza di supporto/feedback della comunità in quel momento. Ora sembra che ci siano più cose, guardando http://repo.or.cz/w/TortoiseGit.git. – Macke
Sembra che git abbia incorporato emailed patches functionality. Non l'ho usato comunque, quindi non posso parlare per la sua utilità.
Poiché l'altro sviluppatore non ha familiarità con i concetti di controllo di revisione, suggerisco di iniziare lentamente.
Il mio flusso di lavoro suggerito consiste in un repository dalla tua parte che può "git clone". Mostragli come può recuperare i cambiamenti da questo e fargli spedire le sue modifiche indietro a te. Mostragli come git può spedire i changeset in giro. In questo modo, sarai quello che dovrà preoccuparsi dei conflitti di modifica che tendono ad essere una grande fonte di confusione per le persone che non hanno mai usato i sistemi di controllo delle versioni prima.
Lo stai scrivendo con un ragazzo che non usa mai il controllo di versione prima? Spaventoso! –