Quale dovrebbe essere il flusso di lavoro con un repository git?

Presumo con questa risposta che sia tu che il tuo capo lavorate sugli stessi repository, quindi state facendo delle vere e proprie fusioni, piuttosto che veloci.

Se hai ri-basato il tuo lavoro sulla testa del tuo repository condiviso, hai fatto tutto il possibile tu per mantenere lineare la cronologia.

Se desidera una cronologia lineare per le proprie modifiche, deve seguire la stessa procedura in cui si aspetta e rebase le sue modifiche locali sulla testa del repository condiviso.

Così com'è, penso che stia vivendo nel passato con una storia lineare, ma è un desiderio comune con persone che sono state punse troppe volte dalla gestione delle filiali nei vecchi sistemi VCS. Fino a quando non riuscirai a persuaderlo altrimenti, hai il peggiore dei due mondi, provando a calzare un flusso di lavoro lineare in un ambiente utilizzando un DVCS in cui ci si aspetta che la ramificazione sia la norma.

Sembra che il tuo capo abbia deciso che il modo in cui le sue cose funzioneranno e ti sta dicendo di aggirare il problema, anche se il modo in cui lo desidera non si allinea con il flusso naturale dei sistemi distribuiti. (Ha anche qualche problema con la microgestione e la fiducia dei suoi dipendenti, ma non è questo il vero problema.)

Un modello di branching Git riuscito
Questa è una descrizione ben scritta e dettagliata di un modello di ramificazione. Ti consente di mantenere le cose organizzate e seguire il flusso delle modifiche. Parla anche del concetto di avere un'origine "centralizzata" che tutti possono spingere e tirare, invece di dover unirsi a tutti quelli della tua squadra.

Il pensiero che mi piace di più di quell'articolo è la sua posizione sulla fusione.

git merge --no-ff myfeature

L'arresto dell'avanzamento veloce significa che il fatto che il ramo esistesse rimane intatto. Quindi, quando si visualizza il grafico del registro

git log --oneline --graph

vedrai il ramo e unisci i punti e segui i diversi percorsi anche quando più persone lavorano in parallelo.

Ci sono diversi problemi qui:

• Usare git su svn.

git è migliore perché è distribuito.
git è diventato anche uno standard a causa di problemi come questo.

• Rapporti con il tuo capo.

Chiaramente sei in una situazione difficile. In situazioni come questa, i commenti "stop by" o "hallway" non funzioneranno. Ti consiglierei di richiedere un incontro formale con lui / lei su un oggetto di cui sei molto preoccupato. Usa quella lingua "molto preoccupata" nella tua richiesta di riunione ma NON dire di cosa si tratta affatto. Questo attirerà la sua attenzione!

• Standard di settore.

Con lo sviluppo di oggi è molto importante tenersi aggiornati sugli strumenti e le cose cambiano rapidamente. A differenza di quando programmavo 30 anni fa e gli strumenti potevano essere standard per un decennio. Prenderò in considerazione l'uso di questo e di altri post nel tuo incontro con il tuo capo ... anche se questa domanda e le risposte probabilmente le faranno incazzare a causa delle critiche. Quindi forse altre domande sullo stesso argomento.

Nota finale:
Il mio ultimo capo ha usato svn e quando ho cercato di parlare di come fosse meglio fare git, ho avuto l'accorto "svn è un sistema perfettamente buono, l'ho usato per anni, non è come se fosse caduto lungo la strada". La verità è venuta fuori quando qualcuno - ok sono stato io - ha sbagliato un po 'di codice. Ha poi avuto un duro periodo di tempo per farlo tornare indietro. Abbastanza ironico visto che questo è un punto super importante di un sistema di controllo della versione. Quindi, in pratica, svn ha funzionato bene ... fino a quando abbiamo effettivamente avuto bisogno di funzionalità chiave. Probabilmente avrei dovuto sapere questo dato che non era stato a gruppi di utenti in 3 anni, non ha un buon account SO, ecc Date le vostre descrizioni vorrei anche ripulire quel curriculum e assicurarmi di essere in contatto con il mercato! La gente con cui vuoi lavorare sarà felice che tu stia usando git!