Perché esattamente l'approccio pull and push di Git è migliore rispetto all'approccio di lockage e hijacking di Clearcase?

Prima di tutto, Git è un VCS decentralizzato (al contrario di ClearCase, che è molto centralizzato: vedi " Quali sono i concetti base di clearcase che ogni sviluppatore dovrebbe conoscere? ")

Ciò significa che non esiste un server centrale per tenere traccia di un file "bloccato".

In secondo luogo, in genere non tiri ma pull --rebase con autostash per riprodurre nuovamente il tuo locale (non ancora spinto) modifica in cima a qualsiasi modifica concomitante (spinte).

Questo è il flusso di lavoro naturale per consentire la collaborazione simultanea.
Nota che ClearCase consente anche modifiche simultanee, almeno nelle viste istantanee (ma tu non è facile stabilire quale file dirottato è stato modificato ).

Infine, non c'è molto da fare per il vecchio modello (1985) ClearCase (vedi " ClearCase vantaggi / svantaggi "). Usarlo nel 2015 è un anacronismo, poiché non si adatta bene a un numero elevato di file, a meno che non si stiano utilizzando visualizzazioni dinamiche e, anche in questo caso, qualsiasi unione è terribilmente lenta.
Se hai per continuare a utilizzare uno strumento IBM, considera almeno RTC (Rational Team Concert) . ha un meccanismo di blocco .

Scegli la tua scelta - preferisci sempre ricevere un avviso quando potrebbe essere un potenziale conflitto nel prossimo futuro poiché due persone modificheranno lo stesso file (Clearcase)? O preferisci ricevere un avvertimento quando il VCS rileva che è un conflitto reale poiché le due persone hanno modificato le stesse linee del codice sorgente, o linee molto vicine l'una all'altra (Git)?

Il primo modello produce alcuni falsi positivi di tanto in tanto, il che può essere fastidioso. Ad una prima occhiata, il secondo modello sembra avere un rischio più elevato di introdurre bachi. Questo perché quando un'unione ha successo formalmente e non ricevi alcun avvertimento, c'è un certo rischio di avere un conflitto "semantico", rivelato solo dai test. Tuttavia, per la mia esperienza, in realtà il secondo è trascurabile - non ricordo di aver mai incontrato una situazione del genere negli ultimi 10 anni. Inoltre, il primo modello ha lo stesso rischio, poiché solo perché ricevi un avvertimento su una modifica simultanea in anticipo non garantisce automaticamente che i due sviluppatori esaminino i risultati della fusione in seguito con maggiore attenzione.

In un caso, la persona che chiude per primo vince. Nell'altro caso la persona che è pronta a spingere prima le vittorie. Il più delle volte, la persona che vuoi avere la precedenza è quella che è pronta a spingere. Se ho una settimana rimasta sulla mia nuova funzione e hai risolto un bug per la versione di oggi, dovresti avere la priorità al momento del check-in.

Questo porta a camminare molto facendo in modo che altre persone possano rilasciare le serrature non urgenti in modo da poter controllare il tuo cambiamento urgente. Ad alcune persone piace perché "costringe una conversazione", ma in realtà non lo fa. Quelle persone fastidiose che apportano modifiche significative senza comunicare correttamente possono comunque apportare tali modifiche su copie dirottate e attendere che tali file vengano sbloccati. Per lo più finisci per infastidire le persone per lo stesso risultato finale: chi è pronto a fare il check-in per primo fa così, e costringe le persone che effettuano il check-in in seguito a unirsi.

Sono state apportate modifiche al commit, ma sono basate su una versione precedente. Non va bene. In qualsiasi sistema di controllo del codice sorgente, è possibile rebase delle modifiche in modo che siano ora basate sulla versione corrente. Non è automatico, è lavoro, potrebbero esserci conflitti, ma è inevitabile. Finora, tutto è lo stesso.

Tuttavia, poiché il processo di ridefinizione e ripetizione delle modifiche ha richiesto tempo, al momento del completamento è possibile che si verifichino nuove modifiche in base a una versione precedente. Di solito questa è solo sfortuna (hai ribadito il tuo codice per includere le modifiche di Joe, e proprio in quel momento Jim ha dovuto controllare il lavoro del suo ultimo mese). Con un team più grande e le persone a volte lavorano sugli stessi file, questo può essere un problema.

Con git, le tue scelte sono: O essere veloce, o chiedere ad altri sviluppatori di non commettere nulla finché non hai finito. Con altri sistemi, puoi bloccare i file, quindi gli altri sviluppatori non possono commettere, il che è proprio lo stesso, tranne che non vai alla loro scrivania e loro non possono dire di no. Non c'è molta differenza nella pratica, supponendo che non si stiano bloccando i file e quindi li si mantenga bloccati per anni. Farei sempre un primo rebase senza dirlo a nessuno, per evitare di disturbare troppo gli altri.