Controllo del codice sorgente basato su Git nell'azienda: strumenti e pratiche suggeriti?

Uso git per progetti personali e penso che sia fantastico. È veloce, flessibile, potente e funziona alla grande per lo sviluppo remoto.

Ma ora è obbligatorio al lavoro e, francamente, abbiamo problemi.

Fuori dagli schemi, git non sembra funzionare bene per lo sviluppo centralizzato in una grande organizzazione (20+ sviluppatori) con sviluppatori di diverse abilità e livelli di sofisticazione git, specialmente rispetto ad altri sistemi di controllo del codice sorgente come Perforce o Subversion, che sono rivolti a quel tipo di ambiente. (Sì, lo so, Linus non l'ha mai pensato per quello.)

Ma - per ragioni politiche - siamo bloccati con git, anche se fa schifo per quello che stiamo cercando di fare con esso.

Ecco alcune delle cose che stiamo vedendo:

• Gli strumenti della GUI non sono maturi
• Utilizzando gli strumenti della riga di comando, è molto facile rovinare un'unione e cancellare le modifiche di qualcun altro
• Non offre autorizzazioni di repository per utente oltre ai privilegi di sola lettura o lettura-scrittura globali
• Se hai un'autorizzazione per QUALSIASI parte di un repository, puoi fare la stessa cosa su OGNI parte del repository, quindi non puoi fare qualcosa come creare un ramo di monitoraggio di piccoli gruppi sul server centrale che altre persone non possono scherzare con.
• Flussi di lavoro diversi da "tutto va bene" o "dittatore benevolo" sono difficili da incoraggiare, figuriamoci imporre
• Non è chiaro se sia meglio usare un unico grande repository (che consente a tutti di fare confusione con tutto) o molti repository per componente (che creano mal di testa nel tentativo di sincronizzare le versioni).
• Con più repository, inoltre, non è chiaro come replicare tutte le fonti di qualcun altro estraendole dal repository centrale, o come ottenere tutto alle 4:30 di ieri pomeriggio.

Tuttavia, ho sentito che le persone utilizzano git con successo nelle grandi organizzazioni di sviluppo.

Se ti trovi in ​​quella situazione, o se in genere disponi di strumenti, suggerimenti e trucchi per rendere più semplice e produttivo l'utilizzo di git in una grande organizzazione in cui alcune persone non sono fan della riga di comando, mi piacerebbe sapere cosa hai suggerire.

A proposito, ho già posto una versione di questa domanda su LinkedIn e non ho ottenuto risposte reali ma un sacco di "accidenti, mi piacerebbe saperlo anche questo!"

AGGIORNAMENTO: Permettimi di chiarire ...

Dove lavoro, non possiamo usare NULLA oltre a git . Non è un'opzione. Siamo bloccati con esso. Non possiamo usare mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS o anche il buon vecchio proiettore di Apple che ho usato nel 1987. Quindi, anche se sei il benvenuto per discutere di altre opzioni, non otterrai la taglia se non discuti di git.

Inoltre, sto cercando suggerimenti pratici su come utilizzare git in azienda . Ho messo un intero elenco di problemi che abbiamo in cima a questa domanda. Ancora una volta, le persone sono benvenute per discutere di teoria, ma se vuoi guadagnare la taglia, dammi delle soluzioni.

Contro l'opinione comune, penso che l'utilizzo di un DVCS sia la scelta ideale in un ambiente aziendale perché consente flussi di lavoro molto flessibili. Parlerò dell'utilizzo di un DVCS contro CVCS prima, delle migliori pratiche e poi di git in particolare.

DVCS vs CVCS in un contesto aziendale:

Non parlerò dei pro / contro generali qui, ma piuttosto mi concentrerò sul tuo contesto. È l'idea comune che l'utilizzo di un DVCS richieda un team più disciplinato rispetto all'utilizzo di un sistema centralizzato. Questo perché un sistema centralizzato ti fornisce un modo semplice per applicare il tuo flusso di lavoro, l'utilizzo di un sistema decentralizzato richiede più comunicazione e disciplina per attenersi alle convenzioni stabilite. Anche se questo può sembrare che induca un sovraccarico, vedo un vantaggio nella maggiore comunicazione necessaria per renderlo un buon processo. Il tuo team dovrà comunicare sul codice, sui cambiamenti e sullo stato del progetto in generale.

Un'altra dimensione nel contesto della disciplina è incoraggiare le ramificazioni e gli esperimenti. Ecco una citazione dalla recente voce bliki di Martin Fowler sugli strumenti di controllo della versione , ha trovato una descrizione molto concisa per questo fenomeno.

DVCS incoraggia la ramificazione rapida per la sperimentazione. Puoi fare branch in Subversion, ma il fatto che siano visibili a tutti scoraggia le persone dall'aprire un branch per lavori sperimentali. Allo stesso modo, un DVCS incoraggia il controllo del lavoro: inviare modifiche incomplete, che potrebbero non compilare o superare i test, nel tuo repository locale. Ancora una volta potresti farlo su un ramo sviluppatore in Subversion, ma il fatto che tali rami siano nello spazio condiviso rende le persone meno propense a farlo.

DVCS consente flussi di lavoro flessibili perché forniscono il tracciamento dei gruppi di modifiche tramite identificatori univoci globali in un grafico aciclico diretto (DAG) invece di semplici differenze testuali. Ciò consente loro di tracciare in modo trasparente l'origine e la cronologia di un changeset, il che può essere piuttosto importante.

Flussi di lavoro:

Larry Osterman (uno sviluppatore Microsoft che lavora nel team Windows) ha un ottimo post sul blog sul flusso di lavoro che impiegano nel team Windows. In particolare hanno:

• Un trunk solo codice pulito e di alta qualità (repository principale)
• Tutto lo sviluppo avviene sui rami delle funzionalità
• I team di funzionalità dispongono di repository di team
• Fanno regolarmente unire le ultime modifiche al trunk nel loro ramo di funzionalità ( Forward Integrate )
• Le funzionalità complete devono superare diversi controlli di qualità, ad esempio revisione, copertura di test, domande e risposte (repository da soli)
• Se una funzione è completata e ha una qualità accettabile, viene unita al tronco ( integrazione inversa )

Come puoi vedere, avendo ciascuno di questi repository vivere da solo puoi disaccoppiare diversi team che avanzano a ritmi diversi. Anche la possibilità di implementare un sistema di controllo qualità flessibile distingue DVCS da CVCS. Puoi risolvere i tuoi problemi di autorizzazione anche a questo livello. Solo a poche persone dovrebbe essere consentito l'accesso al repository principale. Per ogni livello della gerarchia, disporre di un repository separato con le politiche di accesso corrispondenti. In effetti, questo approccio può essere molto flessibile a livello di squadra. Dovresti lasciare che ogni squadra decida se vogliono condividere il loro repository di squadra tra di loro o se vogliono un approccio più gerarchico in cui solo il capo del team può impegnarsi nel repository del team.

(L'immagine è stata rubata da hginit.com di Joel Spolsky .)

Una cosa resta da dire a questo punto però: - anche se DVCS fornisce grandi capacità di fusione, questo non è mai un sostituto per l'utilizzo dell'integrazione continua. Anche a quel punto hai una grande flessibilità: CI per il trunk repo, CI per i repository di team, Q&A repo ecc.

Git in un contesto aziendale:

Git forse non è la soluzione ideale per un contesto aziendale come hai già sottolineato. Ripetendo alcune delle tue preoccupazioni, penso che in particolare siano:

• Supporto ancora un po 'immaturo su Windows (correggimi se è cambiato di recente) Ora Windows ha il client Windows GitHub , tortoisegit , SourceTree di atlassian
• Mancanza di strumenti GUI maturi, nessuna integrazione di strumenti citizen vdiff / merge di prima classe
• Interfaccia incoerente con un livello molto basso di astrazioni in cima al suo funzionamento interno
• Una curva di apprendimento molto ripida per gli utenti svn
• Git è molto potente e rende facile modificare la cronologia, molto pericoloso se non sai cosa stai facendo (ea volte lo farai anche se pensavi di saperlo)
• Nessuna opzione di supporto commerciale disponibile

Non voglio iniziare qui una guerra tra git e hg, hai già fatto il passo giusto passando a un DVCS. Mercurial affronta alcuni dei punti sopra e penso che sia quindi più adatto in un contesto aziendale:

• Sono supportate tutte le piattaforme che eseguono python
• Ottimi strumenti GUI su tutte le principali piattaforme (win / linux / OS X), integrazione di strumenti merge / vdiff di prima classe
• Interfaccia molto coerente, facile transizione per gli utenti svn
• Può fare la maggior parte delle cose che può fare anche git, ma fornisce un'astrazione più pulita. Le operazioni pericolose sono sempre esplicite. Le funzionalità avanzate vengono fornite tramite estensioni che devono essere abilitate esplicitamente.
• Il supporto commerciale è disponibile da selenic.

In breve, quando si utilizza DVCS in un'azienda, penso sia importante scegliere uno strumento che introduca il minimo attrito. Affinché la transizione abbia successo, è particolarmente importante considerare le diverse abilità tra gli sviluppatori (per quanto riguarda VCS).

Riduzione dell'attrito:

Ok, dal momento che sembra che tu sia davvero bloccato con la situazione, ci sono due opzioni rimaste IMHO. Non esiste uno strumento per rendere git meno complicato; git è complicato. O affronti questo o aggiri git: -

1. Ottieni un corso introduttivo git per tutto il team. Questo dovrebbe includere solo le basi e alcuni esercizi (importanti!).
2. Converti il ​​repository master in svn e lascia che "young-stars" git-svn . Ciò offre alla maggior parte degli sviluppatori un'interfaccia facile da usare e può compensare la mancanza di disciplina nel tuo team, mentre le giovani star possono continuare a utilizzare git per i propri repository.

Ad essere onesti, penso che tu abbia davvero un problema di persone piuttosto che un problema di strumenti. Cosa si può fare per migliorare questa situazione?

• Dovresti chiarire che pensi che il tuo processo attuale finirà con una base di codice gestibile.
• Investite un po 'di tempo nell'integrazione continua. Come ho sottolineato sopra, indipendentemente dal tipo di VCS che usi, non c'è mai un sostituto per CI. Hai affermato che ci sono persone che inseriscono schifezze nel repository principale: chiedi loro di aggiustare le loro schifezze mentre si attiva un avviso rosso e le incolpa per aver rotto la build (o non soddisfano una metrica di qualità o altro).

Sono l'ingegnere SCM per un'organizzazione di sviluppo ragionevolmente grande e ci siamo convertiti a git da svn nell'ultimo anno circa. Lo usiamo in modo centralizzato.

Usiamo gitosis per ospitare i repository. Abbiamo suddiviso i nostri repository svn monolitici in molti repository git più piccoli poiché l'unità di ramificazione di git è fondamentalmente il repository. (Ci sono modi per aggirare questo problema , ma sono imbarazzanti.) Se vuoi tipi di controlli di accesso per ramo, gitolite potrebbe essere un approccio migliore. C'è anche una versione all'interno del firewall di GitHub se ti interessa spendere i soldi. Per i nostri scopi, gitosis va bene perché abbiamo autorizzazioni abbastanza aperte sui nostri repository. (Abbiamo gruppi di persone che hanno accesso in scrittura a gruppi di repository e tutti hanno accesso in lettura a tutti i repository.) Usiamo gitweb per un'interfaccia web.

Per quanto riguarda alcune delle tue preoccupazioni specifiche:

• unisce: è possibile utilizzare uno strumento di unione visiva di propria scelta; ci sono istruzioni in vari punti su come configurarlo. Il fatto che tu possa fare l'unione e verificarne la validità totalmente sul tuo repository locale è, a mio parere, un grande vantaggio per git; puoi verificare l'unione prima di inviare qualsiasi cosa.
• GUI: alcune persone usano TortoiseGit ma non lo consiglio davvero; sembra interagire in modi strani con la riga di comando. Devo ammettere che questa è un'area che necessita di miglioramenti. (Detto questo, non sono un fan delle GUI per il controllo della versione in generale.)
• rami di tracciamento per piccoli gruppi: se utilizzi qualcosa che fornisce ACL più fini come gitolite, è abbastanza facile farlo, ma puoi anche creare un ramo condiviso collegando i repository locali di vari sviluppatori: un repository git può avere più telecomandi.

Siamo passati a git perché abbiamo molti sviluppatori remoti e perché abbiamo avuto molti problemi con Subversion. Stiamo ancora sperimentando i flussi di lavoro, ma al momento lo usiamo fondamentalmente nello stesso modo in cui usavamo Subversion. Un'altra cosa che ci è piaciuta è che ha aperto altri possibili flussi di lavoro, come l'uso di repository di staging per la revisione del codice e la condivisione del codice tra piccoli gruppi. Ha anche incoraggiato molte persone a iniziare a tenere traccia dei propri script personali e così via perché è così facile creare un repository.

Sì, lo so, Linus non l'ha mai pensato per quello.

In realtà, Linus sostiene che i sistemi centralizzati non possono funzionare.

E cosa c'è di sbagliato nel flusso di lavoro del dittatore e dei luogotenenti?

Ricorda, git è un sistema distribuito ; non provare a usarlo come uno centrale.

(Aggiornato)

La maggior parte dei tuoi problemi scomparirà se non provi a usare git come se fosse "svn on steroids" (perché non lo è).

Invece di utilizzare un semplice repository come server centrale in cui tutti possono eseguire il push (e potenzialmente rovinare), configurare alcuni gestori di integrazione che gestiscono le fusioni, in modo che solo loro possano eseguire il push nel semplice repository.

Di solito queste persone dovrebbero essere i leader del team: ogni leader integra il lavoro del proprio team e lo spinge nel repository benedetto.

Ancora meglio, qualcun altro (ad esempio il dittatore) attinge dai team leader e integra le loro modifiche nel repository benedetto.

Non c'è niente di sbagliato in quel flusso di lavoro, ma siamo una startup oberata di lavoro e abbiamo bisogno dei nostri strumenti per sostituire il tempo e l'attenzione umana; nessuno ha la larghezza di banda nemmeno per fare le revisioni del codice, figuriamoci essere un dittatore benevolo.

Se gli integratori non hanno tempo per rivedere il codice, va bene, ma è comunque necessario disporre di persone che integrino le unioni da tutti.

Fare git pull non richiede molto tempo.

git pull A
git pull B
git pull C

git fa sostituto tempo umano e attenzione; ecco perché è stato scritto in primo luogo.

• Gli strumenti della GUI non sono maturi

Gli strumenti della GUI possono gestire le cose di base abbastanza bene.

Le operazioni avanzate richiedono una mentalità da codificatore / nerd (ad esempio, sono a mio agio a lavorare dalla riga di comando). Ci vuole un po 'di tempo per comprendere i concetti, ma non è così difficile.

• Utilizzando gli strumenti della riga di comando, è molto facile rovinare un'unione e cancellare le modifiche di qualcun altro

Questo non sarà un problema a meno che tu non abbia molti sviluppatori incompetenti con pieno accesso in scrittura al "repository centrale".

Tuttavia, se imposti il ​​tuo flusso di lavoro in modo che solo poche persone (integratori) scrivano al repository "benedetto", non sarà un problema.

Git non rende facile rovinare le fusioni.

Quando ci sono conflitti di unione, git contrassegna chiaramente le linee in conflitto in modo da sapere quali modifiche sono tue e quali no.

È anche facile cancellare il codice di altre persone con svn o qualsiasi altro strumento (non distribuito). In effetti, è molto più facile con questi altri strumenti perché tendi a "sederti sui cambiamenti" per molto tempo e ad un certo punto le fusioni possono diventare terribilmente difficili.

E poiché questi strumenti non sanno come unire, finisci per dover sempre unire le cose manualmente. Ad esempio, non appena qualcuno effettua un commit su un file che stai modificando localmente, verrà contrassegnato come un conflitto che deve essere risolto manualmente; ora quello è un incubo di manutenzione.

Con git, la maggior parte delle volte non ci saranno conflitti di unione perché git può effettivamente unire. Nel caso in cui si verifichi un conflitto, git segnerà chiaramente le linee per te in modo che tu sappia esattamente quali cambiamenti sono tuoi e quali cambiamenti provengono da altre persone.

Se qualcuno cancella i cambiamenti di altre persone mentre risolve un conflitto di unione, non sarà per errore: sarà o perché era necessario per la risoluzione del conflitto, o perché non sanno cosa stanno facendo.

• Non offre autorizzazioni di repository per utente oltre ai privilegi di sola lettura o lettura-scrittura globali

• Se hai un'autorizzazione per QUALSIASI parte di un repository, puoi fare la stessa cosa su OGNI parte del repository, quindi non puoi fare qualcosa come creare un ramo di monitoraggio di piccoli gruppi sul server centrale che altre persone non possono scherzare con.

• Flussi di lavoro diversi da "tutto va bene" o "dittatore benevolo" sono difficili da incoraggiare, figuriamoci imporre

Questi problemi scompariranno quando smetterai di provare a usare git come se fosse un sistema centralizzato.

• Non è chiaro se sia meglio usare un unico grande repository (che consente a tutti di fare confusione con tutto) o molti repository per componente (che creano mal di testa nel tentativo di sincronizzare le versioni).

Chiamata di giudizio.

Che tipo di progetti hai?

Ad esempio: la versione xy del progetto A dipende esattamente dalla versione wz del progetto B in modo tale che ogni volta che controlli xy del progetto A devi anche fare il checkout wz del progetto B, altrimenti non verrà compilato? Se è così, metterei sia il progetto A che il progetto B nello stesso repository, poiché sono ovviamente due parti di un singolo progetto.

La migliore pratica qui è usare il cervello

• Con più repository, inoltre, non è chiaro come replicare tutte le fonti di qualcun altro estraendole dal repository centrale, o come ottenere tutto alle 4:30 di ieri pomeriggio.

Non sono sicuro di cosa intendi.

Consiglio vivamente http://code.google.com/p/gerrit/ per il lavoro aziendale. Ti offre il controllo degli accessi e un flusso di lavoro basato sulla revisione integrato. Si autentica contro qualsiasi sistema LDAP. Puoi collegarlo a Hudson con http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin , permettendoti di creare e testare le modifiche mentre sono ancora in fase di revisione; è una configurazione davvero impressionante.

Se decidi di usare gerrit, ti consiglio di provare a mantenere una cronologia piuttosto lineare, non una storia ramificata come piace ad alcuni ragazzi open source. Gerrit lo formula come "consenti solo modifiche in avanti veloce". Quindi puoi usare la ramificazione e l'unione in più nel modo in cui sei abituato, per i rilasci e quant'altro.

Rispondo a questa domanda sulla base della mia esperienza come developer manager in una grande società di telecomunicazioni, dove abbiamo adottato Git nel 2010

Hai una serie di problemi abbastanza diversa qui:

• flussi di lavoro
• strumenti client
• controllo e integrazione degli accessi al server

Flussi di lavoro

Abbiamo adottato con successo una modalità di repository centrale: quello che abbiamo nel nostro progetto aziendale (un grande portale per una base di 5 milioni di utenti) è un repository centrale di fatto che produce le build ufficiali che poi vengono prese attraverso il processo di consegna (che, nel nostro caso, è composto da tre livelli di test e due distribuzioni). Ogni sviluppatore gestisce il proprio repository e noi lavoriamo ramo per funzionalità.

Strumenti client

Ora ci sono diverse opzioni disponibili, questa è ora una zona molto affollata. Molti sviluppatori stanno utilizzando con successo IntelliJ Idea ed Eclipse con il plugin Git , senza altre cose. Inoltre, la maggior parte degli sviluppatori Linux utilizza il client git CLI, senza alcun problema. Alcuni sviluppatori Mac stanno utilizzando con successo Tower Git . Si noti che nessuno di questi client può impedire all'utente di "fare confusione" con il repository centrale: è necessario un meccanismo di controllo lato server

Controllo e integrazione degli accessi al server

Se vuoi evitare che gli sviluppatori "rovinino" il tuo repository Git, devi davvero scegliere una soluzione che:

• espone un'interfaccia di amministrazione web decente per eseguire ogni operazione
• ti permette di imporre le identità degli utenti (usare un repository Git "nudo" è estremamente facile da eseguire per conto di qualcun altro)
• ti fornisce una sicurezza granulare (in modo che, ad esempio, puoi impedire FORCE-PUSH e impostare alcuni rami in modo che leggano solo per alcuni sviluppatori / gruppi)
• integrarsi con il sistema di autenticazione aziendale (es. LDAP, Windows ActiveDirectory)
• fornisce un controllo completo (la conformità SOX a volte è molto importante per le grandi aziende)

Non ci sono così tante soluzioni lato server pronte all'uso che possono aiutare questo, ti suggerisco di dare un'occhiata a una di queste:

• Gitorious : può fornire la sicurezza del livello di accesso di base, ma manca di controllo delle autorizzazioni granulari, quindi probabilmente dovrai fare un po 'di codice per gestire scenari come i permessi a livello di ramo. Inoltre manca l'integrazione con i meccanismi di autenticazione aziendale esistenti
• GitHub Enterprise: recentemente pubblicato da GitHub, include GitHub nella tua azienda. Manca la conformità SOX e la sicurezza a grana fine
• Gerrit : può fornire sicurezza a livello di accesso a grana fine e integrazione con i sistemi di autenticazione aziendale, ma manca di conformità SOX e SSO. Inoltre, alcune operazioni possono essere eseguite solo tramite SSH tramite CLI
• GitEnterprise : fornisce autorizzazioni a livello di filiale, SSO, conformità SOX, amministrazione basata sul web completa. Di recente è stato anche integrato con Gerrit, in modo da fornire anche un'istanza di Gerrit completa

Spero che questo ti aiuti!

Sembra che il tuo problema sia che non hai deciso o istituito un flusso di lavoro. Git è abbastanza flessibile da usarlo come svn o qualsiasi altro VCS, ma è così potente che se non stabilisci regole che tutti devono seguire, ti ritroverai con un pasticcio. Consiglierei il flusso di lavoro dittatore-luogotenente che qualcuno ha menzionato sopra, ma combinato con il modello di ramificazione descritto da Vincent Driessen . Per maggiori informazioni guarda questi screencast di David Bock e questo di Mark Derricutt .

Sugli strumenti , gli utenti di MacOS-X trovano GitX (http://gitx.frim.nl/) molto semplice ed efficace. Lo svantaggio è che non supporta gli hook Git Client (quelli sotto $ GIT_ROOT / .git / hooks).

Nel complesso, scelgo fortemente uno strumento che supporti un controllo di accesso granulare su: - rami (al fine di separare i rami di rilascio stabili con una sicurezza rigorosa dai rami argomento che richiedono maggiore agilità e flessibilità) - applicazione dell'identità (autore / committer ). Questa è la CHIAVE per SOX - restrizioni dei comandi git - audit-trail. Questa è la CHIAVE per SOX

Quelli che ho utilizzato con successo con queste funzionalità sono:

1. Gerrit Code Review (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), utilizza Gerrit 2.1.8 dietro le quinte

PS Non sottovalutare la conformità SOX e CMMI : molte volte c'è una serie limitata di scelta che è dettata dalle politiche aziendali sulla sicurezza della tua azienda.

Spero che questo ti aiuti.

Luca.

Recentemente siamo passati da svn a git. Poiché git-daemon non funziona con msysgit, abbiamo optato per un approccio di repository centrale su un server Linux con gitosis.

Per eliminare la possibilità di rovinare il master, l'abbiamo semplicemente deltato. Invece, prepariamo tutte le versioni unendo i rami selezionati per il test e contrassegnando l'unione. Se supera i test, il commit viene contrassegnato con una versione e messo in produzione.

Per gestire questo abbiamo un ruolo a rotazione di release manager. Il gestore del rilascio è responsabile della revisione di ogni ramo prima che sia pronto per il test. Quindi, quando il proprietario del prodotto decide che è il momento di raggruppare i rami approvati per un nuovo rilascio di prova, il responsabile del rilascio esegue l'unione.

Abbiamo anche un ruolo a rotazione di help desk di 2 ° livello e almeno per noi il carico di lavoro è tale che è possibile avere entrambi i ruoli contemporaneamente.

Come vantaggio di non avere un master non è possibile aggiungere alcun codice al progetto senza passare attraverso il gestore del rilascio, quindi abbiamo scoperto direttamente quanto codice era stato aggiunto silenziosamente al progetto prima.

Il processo di revisione inizia con il proprietario della filiale che invia il diff al tabellone di revisione e mette un post-it verde sulla lavagna con il nome del ramo (abbiamo un flusso di lavoro basato su Kanban) sotto "per revisione", o se fa parte di un utente completato storia, sposta l'intera scheda della storia su "per revisione" e mettici sopra il postit. Il relase manager è colui che sposta le carte e i post-it in "ready for test" e quindi il product owner può selezionare quali includere nella successiva release di test.

Quando si esegue l'unione, il gestore del rilascio si assicura anche che il commit di unione abbia un messaggio di commit ragionevole che può essere utilizzato nel log delle modifiche per il proprietario del prodotto.

Quando una release è stata messa in produzione, il tag viene utilizzato come nuova base per i rami e tutti i rami esistenti vengono uniti ad esso. In questo modo tutti i rami hanno un genitore comune che semplifica la gestione delle unioni.

Aggiungerò anche un post "hai considerato".

Una delle grandi cose di Bazaar è la sua flessibilità. Qui è dove batte tutti gli altri sistemi distribuiti. Puoi utilizzare Bazaar in modalità centralizzata, modalità distribuita o ottenere questo: entrambi (il che significa che gli sviluppatori possono scegliere con quale modello si trovano a proprio agio o quale funziona meglio per il loro gruppo di lavoro). Puoi anche disconnettere un repository centralizzato mentre sei in viaggio e ricollegarlo quando torni.

Inoltre, un'eccellente documentazione e qualcosa che renderà felice la tua azienda: supporto commerciale disponibile.

• Installa un'interfaccia web decente, come Github FI
• Attenersi a un modello relativamente centralizzato (inizialmente) per mantenere le persone a proprio agio.
• Esegui una build di integrazione continua per ogni ramo condiviso.
• Condividi un buon set di opzioni globali di git config.
• Integra git nella tua shell, con il completamento di bash e un prompt con il ramo corrente.
• Prova Git Integration di IntelliJ come strumento di unione.
• Assicurati di .gitignore come appropriato.

Riguardo ai punti 3 e 4 (permessi per utente, per sezione, per ramo), dai un'occhiata a gitolite (trattato nel libro Pro Git: http://progit.org/book/ch4-8.html ).

Politica o no, Git è una buona scelta di un DCVS come qualsiasi altra. Come ogni strumento potente, vale la pena dedicare un po 'di tempo in anticipo a capire come lo strumento è progettato per funzionare e, a tal fine, consiglio vivamente il libro Pro Git. Un paio d'ore trascorse con esso risparmieranno molte frustrazioni a lungo termine.

GUI: Al momento, TortoiseGit v1.7.6 dovrebbe andare bene per la maggior parte delle operazioni quotidiane. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Aggiungi sottomodulo, ecc ... Supporta anche x64 in modo nativo

Per poter utilizzare git in modo efficiente in un team di sviluppo con molti sviluppatori, è necessario un sistema CI che si compili e collauda continuamente. Jenkins fornisce un veicolo del genere e lo consiglio vivamente. Il pezzo di integrazione deve essere fatto qualunque cosa ed è molto più economico farlo prima e più spesso.

Più adatto per lo sviluppo collaborativo rispetto a gitosis o gitolite, ma l'open-source è Gitorious . È un'applicazione Ruby on Rails che gestisce la gestione dei repository e l'unione. Dovrebbe risolvere molti dei tuoi problemi.

Git permette di creare rami privati. Questo incoraggia gli sviluppatori a impegnarsi spesso in modo da suddividere le modifiche in piccoli commit. Quando lo sviluppatore è pronto per pubblicare le sue modifiche, esegue il push al server centrale. Può fare uso di script pre-commit per verificare il suo codice, se necessario.

NXP gestisce Git e Subversion con una piattaforma comune (su scala aziendale), integrando lo sviluppo mobile Android con progetti software tradizionali: http://www.youtube.com/watch?v=QX5wn0igv7Q