Il nostro team di documentazione composto da una decina di persone è passato di recente da SVN a Git. In SVN, tutti hanno lavorato sul master, un modello che ho sempre odiato, ma non sono stato in grado di realizzare quel cambiamento. Come parte del passaggio a Git, abbiamo deciso di risolvere il problema, ma non possiamo ancora farlo (aspettando modifiche di build che consentano build da rami arbitrari). Nel frattempo, tutti stanno lavorando al master. Sì, lo so che è terribile, credimi.

Stiamo vedendo molti più singhiozzi ora rispetto a quando stavamo usando SVN, alcuni dei quali sono causati dal modello a due stadi di Git (locale e remoto). A volte le persone si impegnano ma non riescono a spingere, oppure tirano e ottengono conflitti con i loro cambiamenti locali in sospeso. Ieri qualcuno ha ostruito i recenti cambiamenti - in qualche modo - con un'unione andata storta, che penso sia stata l'unione che Git fa quando tiri e hai cambiamenti eccezionali. (Non è stato in grado di dirmi esattamente quello che ha fatto, e poiché sta usando una GUI non posso solo controllare la sua storia della shell.)

Come utente Git più esperto (leggi: l'ho usato prima, anche se non per qualcosa di super complicato), sono la persona che imposta la politica, insegna gli strumenti e pulisce i pasticci. Quali modifiche posso apportare al modo in cui stiamo utilizzando gli strumenti per rendere un master condiviso e attivo meno soggetto a errori fino a quando non possiamo passare allo sviluppo sui rami?

Il team sta usando Tortoise Git su Windows. Stiamo usando Tortoise Git perché abbiamo già usato Tortoise SVN. ( Io personalmente uso la linea di comando sotto Cygwin per alcune operazioni, ma la squadra ha messo in chiaro che hanno bisogno di una GUI e stiamo andando con questo.) Le risposte dovrebbero lavorare con questo strumento, non propone sostituzioni.

Tortoise Git ha "Commit & Push" disponibile come singola operazione e ho detto loro di farlo sempre. Tuttavia, non è atomico - può succedere che il commit (che in fondo è locale) funzioni bene ma il push non lo fa (diciamo, a causa di un conflitto o di un problema di rete). Quando ciò accade, ottengono un errore ambiguo; Ho detto loro di controllare il BitBucket commettere registro se hanno eventuali dubbi su un recente commesso e, se non lo vedono, a spingere. (E per risolvere il conflitto se questo è il problema, o chiedere aiuto se non sanno cosa fare.)

La squadra ha già la buona abitudine di "tirare presto e spesso". Tuttavia, sembra che l'attrazione possa causare conflitti, che penso sia nuova? Se non nuovo, molto più frequente rispetto a SVN. Ho sentito che posso cambiare il modo in cui Git fa pull (rebase anziché merge), ma non ho una buona comprensione dei compromessi lì (o di come farlo nel nostro ambiente).

Il server è BitBucket (non Github). Ho il pieno controllo amministrativo sul nostro repository ma nessuno sul server più in generale. Niente di tutto ciò è modificabile.

I file di origine sono XML. Ci sono anche file grafici, che tutti sanno che non puoi unire, ma non abbiamo quasi mai collisioni lì. I conflitti di unione provengono dai file XML, non dalla grafica.

Quali modifiche posso apportare al nostro uso di Git per far sì che il master di condivisione vada più agevolmente per il team fino a quando non potremo passare a utilizzare i rami delle funzionalità con richieste pull verificate e convalidate dai test?

Finora SourceTree è stato l'IDE migliore per apprendere i concetti, perché mostra tutte le finestre di dialogo e le opzioni pertinenti che hai su ogni fase, le opzioni predefinite di solito vanno bene, non scherzare con rebase, ecc. Segui semplicemente il flusso normale:

• Tirati dal maestro, solo per essere sicuro di essere aggiornato
• Modifica i tuoi file
• Conferma le modifiche (solo localmente)
• Tirare di nuovo dal master (questo farà apparire i conflitti)
• Modifica tutti i file fino alla risoluzione dei conflitti, il che significa che il file si trova nello stato di propper che desideri commettere (nessun messaggio principale <<<<< HEAD e >>>> nel file raw)
• Apporta le modifiche di unione
• spingere

Se tutti seguono questa ricetta, dovrebbero andare bene.

Ogni volta che qualcuno fa una modifica più grande o centrale, informa gli altri utenti di impegnarsi localmente e di ritirarsi dal master, in modo che non ottengano troppi conflitti in seguito e la prima persona sia ancora in giro per risolvere i conflitti insieme a loro.

Investi molto tempo nel convincere tutti a capire il flusso, altrimenti potrebbero aggirarsi un po 'e poi sentirsi a proprio agio con esso mentre in realtà si rovina il ramo principale, ad esempio "usa il mio file anziché il telecomando" per risolvere un conflitto semplicemente darà dei calci tutte le modifiche apportate da altre persone.

Git è un sistema difficile da imparare, specialmente se sei cresciuto con Svn, sii paziente e dai loro il tempo di impararlo correttamente, con i nuovi utenti a volte puoi passare una giornata a ripulire un po 'di casino, è normale. ;)

Ci sono tre cose principali da ricordare quando si lavora fuori dallo stesso ramo di qualcun altro:

• Non usare mai --forcese non sai davvero cosa stai facendo.
• Sia commito stashil lavoro in corso prima di ogni pull.
• Di solito diventa più facile se hai pullappena prima di un push.

A parte questo, farò notare che con il controllo della versione distribuita non importa se il tuo repository "ufficiale" utilizza filiali o meno. Ciò non influisce in alcun modo su ciò che i singoli utenti fanno nei loro repository locali. Usavo git per ottenere filiali locali quando la mia azienda utilizzava un VCS centrale completamente diverso. Se creano filiali locali per le loro caratteristiche e commettono errori di fusione con quelle locali master, è molto più facile da risolvere senza andare nel reflog o in qualche altra magia.

È possibile dedicare un giorno affinché tutti imparino il git?

I professionisti che usano il computer dovrebbero davvero imparare un nuovo strumento e, sebbene sia possibile commettere molti errori in qualsiasi VCS, dovrebbero usare lo strumento in quanto è progettato per essere utilizzato.

Il modo migliore per introdurlo è far sì che tutti lavorino sul proprio ramo quando fanno un cambiamento (il più breve possibile) e si riposizionano per poi ricollegarsi al master quando hanno finito. Questo non è troppo lontano dal modo attuale di lavorare e introduce un semplice flusso di lavoro a cui possono abituarsi fino a quando non si sentono abbastanza sicuri da fare operazioni più complicate.

Non uso Windows ma se Tortoise fondamentalmente li nasconde e fingendo che sia SVN, forse Tortoise è lo strumento sbagliato.

A volte, ciò che stai facendo deve cambiare.

Il problema più grande è che tutti stanno lavorando al master. Questo non è tipico per lo sviluppo del codice e potrebbe essere anche il modello sbagliato nel tuo caso. Se puoi cambiarlo, chiedendo / richiedendo che le modifiche vengano fatte su rami separati, avrai una forma molto migliore. Con i rami puoi ottenere quanto segue:

• Applicare che non mastersia consentito alcun push diretto .
• Applicare tramite Bitbucket che le richieste pull vengano create e abbiano almeno un'approvazione prima della fusione . Ciò garantisce che qualcuno stia esaminando le modifiche e rende anche l'unione meno dolorosa, poiché l'interfaccia utente mostrerà conflitti contro la versione remota del codice, non qualunque cosa l'utente abbia sul desktop. Ciò impedisce lo scenario commit-riuscito-ma-push-fallito.
• Esegui "build" sul tuo repository prima della fusione. Mi rendo conto che si tratta di un repository di documenti, ma forse c'è il controllo ortografico, lo scraping del legalese o persino la traduzione automatica (esporta cose STRING_DEF in un file CSV) che potrebbero essere costruite da questa build. O forse no, dipende dal tuo lavoro.
• Consentire alle persone di lavorare su più cose contemporaneamente contemporaneamente più facilmente. Sì, questo può essere fatto anche con gli stash, ma è un po 'più disordinato e qualcosa mi dice che non li stai nemmeno usando.

Se non puoi usare la ramificazione, potresti prendere in considerazione la possibilità di scrivere una merge-and-pushsceneggiatura in grado di automatizzare alcuni dei punti deboli. Forse verificherebbe che l'utente non è in ritardo sul master, fare un recupero e tirare, quindi tentare l'unione ( possibilmente con--no-commit --no-ff ) e così via.

Sottolinea che puoi rifare le fusioni

Potrebbe essere ovvio per te, ma gli ex utenti SVN potrebbero non essere consapevoli di poter provare a risolvere un'unione più volte. Ciò potrebbe ridurre il numero di flag di aiuto ricevuti.

In SVN quando trunkti alleni avresti le modifiche senza impegno in giro. Quindi faresti un svn update. A quel punto i tuoi cambiamenti si mescolerebbero per sempre con quelli degli altri. Non c'era modo di annullarlo (afaik), quindi non avevi altra scelta che controllare manualmente tutto e sperare che il repository fosse in buono stato. Quando davvero ti sentiresti molto più a tuo agio nel rifare l'unione.

Le persone avrebbero avuto la stessa mentalità anche quando ci siamo trasferiti a git. Portando a molti errori involontari.

Fortunatamente con Git c'è un modo per tornare indietro, in particolare perché è possibile effettuare commit locali. (Descriverò in seguito come viene espresso nella riga di comando)

Sebbene il modo in cui ciò avvenga varierà in base agli strumenti. Trovo che ripetere un pull non sia qualcosa di esposto in molte GUI come un singolo pulsante, ma probabilmente è possibile. Mi piace che usi Cygwin. I miei collaboratori usano sourcetree. Dato che usi BitBucket, sarebbe logico usarlo come interfaccia grafica poiché è gestito dalla stessa azienda: Atlassian. Ho il sospetto che ci sia una più stretta integrazione.

Per quanto riguarda i pull

Penso che tu abbia ragione nel fatto che l'unione pullsta nel confondere le persone. A pullè in realtà git fetchche recupera le modifiche dal server, seguito da git merge origin/<branchname>* che unisce le modifiche remote nel ramo locale. ( https://git-scm.com/docs/git-pull )

Il risultato è che tutti i comandi di unione standard funzionano con pull. Se tale unione presenta conflitti, è possibile interrompere git merge --abort. Che dovrebbe riportarti a prima della tua unione. Quindi puoi riprovare con git pullo git merge origin/<branchname>.

Se riesci in qualche modo a imparare come fare sopra usando lo strumento GUI preferito dai tuoi colleghi, penso che risolverà la maggior parte dei tuoi problemi. Scusa, non posso essere più specifico.

* Capisco che l'origine non è sempre il caso qui.

Utilizzare git reflogper diagnosticare problemi

Come te, devo diagnosticare i problemi principalmente creati dall'uso improprio degli strumenti della GUI. Trovo che a git reflogvolte possa essere utile in quanto è una scia abbastanza consistente di azioni sul repository. Anche se a volte è difficile da leggere.

Un'alternativa

Poiché la tua situazione è temporanea , puoi semplicemente tornare a SVN fino a quando non avrai avviato la procedura di implementazione. Non esiterei a farlo, dato che molti posti continuerebbero a dire "Abbiamo provato git una volta ma non ha funzionato ..." e non ho mai recuperato.

Alcuni altri problemi di transizione comuni

• Le persone spesso cancellavano e riposizionavano il loro repository, essendo convinti che il loro repository fosse in uno stato inutilizzabile. Di solito questo è stato causato dalla perdita della traccia della differenza locale e remota. Sia gli strumenti della GUI che la CLI non riescono a mostrarlo bene. Nella CLI trovo git log --decorateil modo più semplice per visualizzare una panoramica delle differenze. Ma se le cose diventano troppo pelose sul master (ad esempio) puoi farlogit reset --hard origin/master

Un possibile meccanismo, adottato da molti team open source, consiste nell'utilizzare il modello di forking - https://www.atlassian.com/git/tutorials/comparing-workflows (assicurati di enunciare chiaramente quando si discute di un flusso di lavoro di forking git ) .

In questo ogni sviluppatore o sotto-team ha il proprio fork del repository che estraggono da BitBucket fornisce un meccanismo per questo , impostando un'origine "a monte" oltre al telecomando predefinito - dovranno ricordarsi di "recuperare a monte "e" unisci remote / upstream / master "su base regolare.

Risolverà probabilmente i problemi del meccanismo di compilazione poiché gli strumenti di compilazione potrebbero essere indirizzati al master su un progetto diverso, ovvero il fork.

È quindi possibile rimuovere dalla maggior parte delle persone la possibilità di spingere direttamente al progetto principale e di creare un team più piccolo di persone con ruoli di revisione e approvazione. Vedi https://www.atlassian.com/git/tutorials/making-a-pull-request

Il posto dove leggere per assicurarsi che qualsiasi controllo desiderabile venga fatto prima dei push è nella sezione git book sui ganci - https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks - puoi utilizzare gli hook pre-commit e pre-push per fare cose come l'esecuzione di alcuni test sull'impegno proposto per garantire che il lavoro sia valido, ecc. - L'unico problema con gli hook lato client è che gli sviluppatori possono disabilitarli o non abilitarli loro.

Sia Tetchise / merge e hook upstream sono disponibili in TortoiseGit.

Questo sembrerà controintuitivo, ma ascoltami:

Incoraggiali a iniziare a sperimentare con git

Una delle cose interessanti di Git è che è sorprendentemente facile rendere qualsiasi operazione locale completamente sicura. Quando ho iniziato a usare git, una delle cose che mi sono ritrovato a fare è stata zippare l'intera directory come backup nel caso avessi rovinato qualcosa. In seguito ho scoperto che si tratta di un kludge enorme e quasi mai realmente necessario per proteggere il tuo lavoro, ma ha la virtù di essere molto sicuro e molto semplice, anche se non sai cosa diavolo stai facendo e come il comando che si desidera provare verrà visualizzato. L'unica cosa che devi evitare quando lo fai è push. Se non spingi nulla, questo è un modo sicuro al 100% per provare tutto quello che vuoi.

La paura di provare cose è uno dei maggiori ostacoli all'apprendimento del git. Ti dà così tanto controllo su tutto ciò che è un po 'scoraggiante. La realtà è che puoi seguire alcune operazioni molto sicure per la maggior parte del tuo uso quotidiano, ma scoprire quali comandi sono quelli richiede un po 'di esplorazione.

Dando loro un senso di sicurezza , saranno molto più disposti a cercare di capire come fare le cose da soli. E saranno molto più autorizzati a trovare un flusso di lavoro personale sulla propria macchina locale che funzioni per loro. E se non tutti fanno la stessa cosa localmente , va bene, purché aderiscano agli standard con ciò che spingono . Se è necessario comprimere l'intero repository prima di eseguire un'operazione per farli sentire in quel modo, va bene; possono imparare modi migliori di fare le cose mentre vanno e mentre provano cose. Qualsiasi cosa per farti iniziare a provare cose e vedere cosa fa.

Questo non significa che l'allenamento sia inutile. Al contrario, la formazione può aiutarti a presentarti a caratteristiche, modelli e norme. Ma non è un sostituto per sedersi e fare effettivamente cose nel lavoro quotidiano. Né git né SVN sono cose di cui puoi semplicemente andare a una lezione e poi sai tutto. Bisogna usare loro per risolvere i vostri problemi di familiarizzare con loro e quali caratteristiche sono adatti per cui i problemi.

Smetti di scoraggiarli dall'apprendere i dettagli di Git

Ho detto di non spingere nulla, il che va contro una delle cose che hai insegnato loro: "Impegnarsi e spingere" sempre. Credo che dovresti smettere di dire loro di fare questo e dire loro di iniziare a fare il contrario. Git ha sostanzialmente 5 "posti" in cui le tue modifiche possono essere:

• Sul disco, senza commit
• Messa in scena ma non impegnata
• In un commit locale
• In una scorta locale
• Repository remoti (solo i commit e i tag vengono mai inseriti e rimossi tra repository diversi)

Invece di incoraggiarli a tirare e spingere tutto in un unico passaggio, incoraggiali a sfruttare questi 5 posti diversi. Incoraggiali a:

• Scarica le modifiche prima che commettano qualcosa.

• Prendi una decisione su come gestire le modifiche recuperate. Le opzioni sono:

  • Esegui il commit delle loro modifiche locali, quindi modificale in cima alle modifiche recuperate.
  • Esegui il commit delle modifiche locali e quindi esegui l'unione con le modifiche recuperate.

  • Annullare le modifiche, unire, quindi rimuovere e risolvere eventuali conflitti.

    Ci sono altre cose, ma non ci entrerò qui. Si noti che un pull è letteralmente solo un recupero e una fusione. Non è come loro; che è loro. (Passando le --rebasemodifiche tira da fetch + merge a fetch + rebase.)

• Metti in scena le loro modifiche e poi esaminale.
• Effettua il commit delle modifiche temporanee e quindi rivedi il commit.
• Spingere separatamente.

Questo li incoraggerà a controllare il loro lavoro prima che sia reso pubblicamente disponibile a tutti, il che significa che colpiranno i loro errori prima. Vedranno il commit e penseranno "Aspetta, non è quello che volevo" e, diversamente da SVN, possono tornare indietro e riprovare prima di spingere.

Una volta che si abituano all'idea di capire dove sono le loro modifiche, possono iniziare a decidere quando saltare i passaggi e combinare determinate operazioni (quando estrarre perché sai già che vuoi recuperare + unire o quando fare clic sull'opzione Commit & Push) .

Questo è in realtà uno degli enormi vantaggi di git su SVN e git è progettato tenendo presente questo modello di utilizzo. SVN, al contrario, assume un repository centrale, quindi non sorprende se gli strumenti per git non sono ottimizzati per lo stesso flusso di lavoro. In SVN, se il tuo commit è sbagliato, l'unica vera risorsa è un nuovo commit per annullare l'errore.

In questo modo in realtà porterà naturalmente alla prossima strategia:

Incoraggiali a usare le filiali locali

Le filiali locali in realtà alleggeriscono molti dei punti deboli del lavoro sui file condivisi. Posso apportare tutte le modifiche che desidero nel mio ramo e non influenzerà mai nessuno poiché non le sto spingendo. Quindi, quando verrà il momento, posso usare tutte le stesse strategie di unione e rebase, solo più facilmente:

• Posso riformulare il mio ramo locale, il che rende banale la fusione in maestro.
• Potrei usare una semplice unione (creare un nuovo commit) nel master per inserire le modifiche del mio ramo locale.
• Posso schiacciare unire il mio intero ramo locale in un unico commit sul master se penso che il mio ramo sia troppo disordinato per essere salvato.

L'uso delle filiali locali è anche un buon inizio per capire una strategia di ramificazione sistematica. Aiuta i tuoi utenti a comprendere meglio le proprie esigenze di ramificazione, in modo da poter scegliere una strategia in base alle esigenze e al livello attuale di comprensione / abilità del team e non solo abbandonare Gitflow perché tutti ne hanno sentito parlare.

Sommario

In breve, git non è SVN e non può essere trattato allo stesso modo. Devi:

• Elimina la paura incoraggiando la sperimentazione sicura.
• Aiutali a capire come Git è diverso in modo che possano vedere come questo cambia il loro normale flusso di lavoro.
• Aiutali a comprendere le funzionalità disponibili per aiutarli a risolvere i loro problemi più facilmente.

Tutto ciò ti aiuterà ad adottare gradualmente un migliore utilizzo di git, fino a quando non raggiungerai il punto in cui puoi iniziare a implementare una serie di standard.

Caratteristiche specifiche

A breve termine, le seguenti idee potrebbero essere di aiuto.

rebase

Hai citato rebase e che non lo capisci davvero nella tua domanda. Quindi, ecco il mio consiglio: prova quello che ho appena descritto. Apporta alcune modifiche localmente mentre qualcun altro le invia. Commetti le modifiche localmente . Comprimere la directory del repository come backup. Scarica le modifiche dell'altra persona. Ora prova a eseguire un comando rebase e guarda cosa succede ai tuoi commit! Puoi leggere infiniti post sul blog o ricevere formazione su rebase e su come dovresti o non dovresti usarlo, ma nulla di tutto ciò è un sostituto per vederlo dal vivo in azione. Quindi provalo .

merge.ff=only

Questo sarà una questione di gusti personali, ma lo consiglierò almeno temporaneamente poiché hai già detto che hai già problemi con la gestione dei conflitti. Consiglio di impostare merge.ffsuonly :

git config --global merge.ff only

"ff" sta per "avanzamento rapido". Una fusione in avanti veloce è quando git non ha bisogno di combinare le modifiche da diversi commit. Sposta semplicemente il puntatore del ramo verso un nuovo commit lungo una linea retta nel grafico.

In pratica, ciò impedisce a git di provare automaticamente a creare commit di unione. Quindi, se commetto qualcosa localmente e poi tiro le modifiche di qualcun altro, invece di provare a creare un commit di unione (e potenzialmente forzando l'utente a gestire i conflitti), l'unione fallirà. In effetti, git avrà eseguito solo a fetch. Quando non ci sono commit locali, l'unione procede normalmente.

Ciò offre agli utenti gli utenti la possibilità di rivedere i diversi commit prima di tentare di unirli e li costringe a prendere una decisione su come gestire al meglio la loro combinazione. Posso rifare, andare avanti con l'unione (usando git merge --no-ffper bypassare la configurazione), o posso anche solo rimandare unendo le mie modifiche per ora e gestirle in seguito. Penso che questo piccolo dosso di velocità aiuterà la tua squadra a evitare di prendere decisioni sbagliate sulle fusioni. Puoi lasciare che il tuo team lo spenga una volta che riescono a gestire meglio le fusioni.

Ho vissuto esattamente la stessa esperienza SVN -> git nella mia azienda e, per esperienza, l'unico rimedio è il tempo. Consenti alle persone di abituarsi agli strumenti, fai loro errori, mostra loro come risolverli. La tua velocità soffrirà per un po 'e le persone perderanno il lavoro, e tutti saranno un po' difficili, ma questa è la natura di cambiare qualcosa di fondamentale come il tuo VCS.

Detto questo, concordo con tutti coloro che ritengono che TortoiseGit sia un ostacolo, piuttosto che un aiuto, così presto nel periodo di transizione. TortoiseGit non è ... una grande GUI nel migliore dei casi, e oscurando il modo in cui git funziona in nome della semplicità, impedisce anche ai tuoi colleghi di comprendere i concetti chiave di Git come il commit in due fasi.

Abbiamo preso la decisione (piuttosto drastica) di forzare gli sviluppatori a usare la riga di comando (git bash o posh-git ) per una settimana, e questo ha funzionato a meraviglia per la comprensione di come git effettivamente funziona e come differisce da SVN. Può sembrare drastico, ma ti suggerisco di provarlo semplicemente perché crea quella comprensione del modello git - e una volta che lo hanno abbassato, i tuoi colleghi possono iniziare a usare qualunque faccia della GUI su git che preferiscono.

Nota finale: ci saranno alcuni dei tuoi colleghi che si lamenteranno di come git funzioni quasi immediatamente, e ci saranno alcuni che non lo faranno mai. Quest'ultimo gruppo, devi solo insegnare agli incantesimi mistici per far arrivare il loro codice dal loro computer locale al server in modo che tutti possano vederlo.

Bene, recentemente ho adattato il seguente flusso di lavoro in modo da non cercare mai il ramo principale:

1) Ognuno usa il proprio ramo, che è inizialmente una copia del ramo principale.

Chiamiamo il ramo master "master" e il mio ramo "my_master".

Ho appena creato il mio ramo dal maestro, quindi è esattamente lo stesso. Comincio a lavorare su una nuova funzionalità sul mio ramo e, una volta terminato, faccio quanto segue.

Attualmente sul mio ramo, ho appena finito di scrivere codice

git add . && git commit -m "Message" && git push

Torna al ramo principale

git checkout master

Tirare se non è aggiornato

git pull

Torna al mio ramo

git checkout my_master

Unisci l'ultimo maestro alla mia filiale

git merge master

Risolvi conflitti e fusioni

Prova di nuovo tutto

Quando tutto viene unito e fissato sul mio ramo, spingilo

git push

Torna al ramo principale

git checkout master

Unisciti al mio ramo

git merge my_master

Impossibile avere conflitti poiché vengono risolti sul proprio ramo con la fusione precedente

Push master

git push

Se tutti lo seguono, il ramo principale sarà pulito.

Quindi abbiamo un team che è passato da TFS a git e ha mantenuto i vecchi modi di pensare. Le regole generali di funzionamento sono più o meno le stesse.

Sì, questo significa che tutti lavorano al master. Questo non è poi così male; e un team abituato a TFS o SVN lo troverà molto naturale.

Procedure generali per renderlo il più indolore possibile:

1. fare git stash && git pull --rebase && git stash popogni mattina
2. impegnarsi presto e spesso (non è necessario spingere immediatamente; possiamo almeno iniziare a sfruttare questo vantaggio di git in anticipo)

3. per spingere esegui il seguente ciclo:

   git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.

Se tutti lavorano al master, non c'è niente che tu possa fare. Le cose saranno inevitabilmente incasinate.

È necessario utilizzare master per i prodotti completati che vengono inviati a un cliente. Si dovrebbe usare di sviluppo per lo sviluppo in corso, e si dovrebbe non permettere a nessuno di spingere per lo sviluppo. Lo standard è che tutti si diramano da dev, apporta le loro modifiche, li spinge da locale a loro filiale sul server ed emette una richiesta push. Quindi qualcuno rivede la modifica e la unisce allo sviluppo.

Per evitare conflitti, tutti uniscono lo sviluppo nel proprio ramo prima di spingere e risolvono i conflitti in quella fase (quindi interessa solo uno sviluppatore a livello locale). Se la fusione con lo sviluppo provocherebbe conflitti, allora non viene unito - lo sviluppatore unisce di nuovo lo sviluppo nel proprio ramo e spinge di nuovo sul server, quindi viene rivisto nuovamente.

Puoi usare sourcetree per esempio per far funzionare questo senza alcun dolore.