Qual è l'argomento per non forzare mai un push in un DVCS (Mercurial)?

La ragione principale per non forzare una spinta è che obbliga tutti gli altri a eseguire rebases o force pull, e qualsiasi ramo in sospeso non si fonderà in modo pulito. Inoltre, quando i principianti non capiscono ancora come usare DVCS, una spinta forzata è di solito un segno che hai dimenticato un passaggio, come fare un pull o unire per primo, e puoi perdere accidentalmente la cronologia o persino il codice commesso.

Ci sono alcuni team che costringono a spingere regolarmente regolarmente. Lo costruiscono nel loro normale flusso di lavoro. Ad esempio, una squadra che lavora su un sottosistema del kernel Linux potrebbe divergere dalla "linea principale", ma forzare regolarmente una spinta per riprendersi. Penso che devi avere un team abbastanza disciplinato e con esperienza DVCS per far sì che funzioni bene,

^{Questo è scritto da una prospettiva git, dato che la forza push non è esclusiva di Mercurial}

Ci sono comandi che ti permettono di cambiare il repository locale del repository. git commit --amend , rebase sono due delle cose più comuni che le persone fanno per modificare la propria cronologia dei repository. Questo è perfettamente accettabile. Ho spesso fatto un git commit --amend dopo aver dimenticato di includere il numero di tracciamento per github nel messaggio. Ma non è senza pericolo (come dice la documentazione )

Ahh, but the bliss of rebasing isn’t without its drawbacks, which can be summed up in a single line:

Do not rebase commits that you have pushed to a public repository.

Il fatto è che il repository pubblico dovrebbe essere aggiunto solo. Aggiunga i commit mentre li crei. Riscrivere il rappresentante pubblico causa ogni sorta di mal di testa e fa sì che tutti coloro che lo hanno formato debbano aggiustare i propri repository per farlo corrispondere.

Ci sono certamente momenti in cui dovrai forzare una spinta. Se veramente hai bisogno di modificare quell'ultimo commit (opponiti a una password), o peggio, devi tornare indietro e trova i vecchi file che contengono dati sensibili .

git push --force è uno strumento. È uno strumento molto pesante che ti permette di fare un bel po 'di riscrittura della storia, ma è ancora uno strumento (le persone hanno scritto anche strumenti più grandi ancora titolati bfg per pulire i repository ). Dire "mai forzare una spinta" ignora tutte le volte in cui fa è necessario riscrivere la cronologia.

In this specific example, we collaborate with a customer and they "skip a step" and force push instead of appropriately pulling and merging. This takes the ambiguity of what code is good, what code is bad, out of their working directory and into the server. Two heads on this branch, which one do I use, etc. I am looking to use a hook to disallow force pushing, I just didn't want to lock down that ability if there was a good use case for it. So far I haven't seen one yet.

Il problema che si sta verificando, tuttavia, non è uno con lo strumento. È un problema con le persone che usano lo strumento. Se non hanno la ... maturità ... per gestire una spinta forzata in modo corretto, allora portarla via da loro. Probabilmente non ne hanno bisogno, non sanno quando dovrebbero usarlo o sono consapevoli dei problemi che causa. Costringendoli a utilizzare un flusso di lavoro adeguato significherà sicuramente più lavoro per loro ... significherà anche meno lavoro per la pulizia. A conti fatti, è probabile che l'utilizzo di un flusso di lavoro migliore ridurrà il lavoro complessivo e renderà le cose più pulite. Una volta che sono pienamente consapevoli di come utilizzare lo strumento e il modo corretto in cui funziona il flusso di lavoro, allora lascia che abbiano nuovamente la toolchain senza ostacoli.