Usare git correttamente in una piccola squadra

14

Quale sarebbe il modo più semplice per usare git correttamente in un piccolo team di circa 5 sviluppatori, con un server che esegue l'applicazione live?

version-control  git 
— ONOZ
fonte
5
Vorrei mettere in dubbio l'utilizzo di git in questo caso. Non vi è alcun vantaggio nell'utilizzare il controllo del codice sorgente decentralizzato, quando tutte le persone sono in una stanza con un server dedicato. E c'è ancora il sovraccarico di tirare / spingere in cima ai commit.
— Euforico,
10
@Euphoric dipende dagli strumenti e dal flusso di lavoro.
3
@ONOZ, descrivi il tuo attuale modo di lavorare in modo più dettagliato.
22
@Euforico - Che atteggiamento incredibilmente ristretto. Per la facilità di diramazione e fusione da solo gito hgbatte la maggior parte dei VCS centralizzati. Riesco a capire che le persone si arrabbiano con le persone che si arrovellano costantemente su quanto siano grandi i DVCS, ma seppellire la testa nella sabbia e rifiutarsi di riconoscere che è possibile sviluppare flussi di lavoro diversi e forse più efficienti con DVCS che senza uno è altrettanto male.
— Mark Booth,
8
@Euforico, usare Git non significa che il tuo controllo del codice sorgente sia "decentralizzato". Lavoro in un piccolo team, usiamo Git e abbiamo ancora un repository centrale. Questo è ciò a cui spingi. L'uso di un DVCS di solito non significa che ogni persona stia tirando da ogni altra persona senza un punto centrale.
— Kyralessa,

Risposte:

11

Ti suggerisco di creare un ramo:

  • produzione
  • maestro
  • Locale

Il ramo di produzione è ramo "vivo". È l'applicazione in uso in questo momento.

Quando è necessario un aggiornamento, uno sviluppatore può inserire il ramo principale nel ramo locale. Quindi, può iniziare a programmare. Alla fine, basta tirare e spingere dal ramo locale dello sviluppatore al master. Un project manager può dare un'occhiata nel ramo principale. Provalo. E quando è pronto, puoi unire la produzione al master. E ora avrai un nuovo software.

— sensorario
fonte
Se ti trovi in ​​una situazione di consulenza o aziendale, potresti anche voler avere una filiale per UAT.
— John MacIntyre,
D'accordo, sto usando questo flusso di lavoro.
— Cheung,
Potresti approfondire il motivo per cui la differenza tra un ramo locale e un master? Posso capire perché vorresti avere una versione di produzione funzionante, ma quando tiri / spingi le modifiche si uniranno automaticamente anche senza una filiale locale, giusto?
— Luc,
1
A causa del ramo locale può essere nominato come XXX-feature-name, quindi, hai ramo master come unione di tutto il ramo di funzionalità che desideri in produzione. Sì: perché alcune funzionalità potrebbero non essere incluse.
— sensorario,
7

Inizia in modo semplice e crea un flusso di lavoro più complesso come e quando è necessario.

Qualunque cosa tu faccia, non lasciare che un modello di ramificazione Git di successo sia la prima cosa che la gente vede, li confonderà e li travolgerà. Guarda più avanti quando hai più esperienza.

Ti suggerirei di iniziare con un gitrepository centrale e di far clonare tutti, compresi i tuoi build di produzione e test.

Nel tuo repository git, crea un productionramo e un testramo.

Gli sviluppatori dovrebbero lavorare nei propri rami di funzionalità locali o remoti fino a quando non vengono completati e uniti master. Da qui possono essere uniti nel testramo per la distribuzione nell'ambiente di test e quando superano i test possono essere uniti nel productionramo.

In questo modo puoi sempre vedere ciò che è nuovo e non testato, ciò che è testato ma non ancora implementato nella produzione e ciò che è effettivamente in produzione.

— Mark Booth
fonte
Opinione interessante, considererei il modello di ramificazione git come un rompiscatole per git, d'altra parte potrebbe non essere così ovvio per gli utenti non git.
— Wirrbel,
@wirrbel Non esistono cose come il modello di ramificazione git, è possibile implementare qualsiasi modello di ramificazione desiderato gitper adattarsi al proprio flusso di lavoro. Quello che propongo qui è semplice ed è probabile che sia migliore per i meno esperti gitutenti di un modello di ramificazione Git successo ma AsGbm è probabile che sia migliore per i più esperti gitutenti, ma non è così adatto per alcune squadre (persone che vogliono mantenere più rilascio rami per esempio). Come ho detto però, il problema con AsGbm è che può sembrare eccessivamente complicato.
— Mark Booth,
Vedo il tuo punto. Solo per me, ho iniziato con AsGbm (o piuttosto adattato alle mie esigenze). È stato perfetto dal momento che ho potuto vedere come git potrebbe essere usato in modo diverso rispetto a svn
— wirrbel,
0

È necessario disporre di un repository principale sul server di integrazione e ogni sviluppatore deve clonarlo. Dopo di ciò basta tirare e spingere. Sviluppa nuove grandi funzionalità in un ramo separato. Nessuna scienza missilistica qui. Sul server live: è inoltre necessario clonare il repository principale. Ed è buona pratica avere un ramo come "live" per questo.

— Nikolay Fominyh
fonte
2
git archive è un'altra opzione per la distribuzione sul server live supponendo che in realtà non si desideri modificare direttamente le cose sul server live
— jk.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.