Git ha una "modalità sicura" per impedire la riscrittura della cronologia?


11

Quando sei un po 'fresco con Git (e DVCS in generale) e inizi a esplorare le modifiche di riscrittura della cronologia, sei sicuro se il repository è solo locale, ma potresti riscontrare problemi se lavori con i telecomandi e provi a spingere tali cambiamenti.

Una caratteristica che mi aspetto è la possibilità di abilitare una "modalità provvisoria" che mi impedirebbe sostanzialmente di fare tutto ciò che non dovrei fare ... E cosa intendo con questo? Intendo cambiamenti di riscrittura della storia per cose già spinte a un'origine. Non riesco a definirlo con precisione, ma ciò includerebbe casi come:

  • commit --amend quando HEAD è già stato premuto
  • rebase di una filiale non locale
  • reset di un ramo che è stato spinto

Questi sono esempi di situazioni che probabilmente faranno pushfallire il prossimo (perché non sarebbe avanzamento veloce, IIRC). Ne ho fatto un po 'per caso e ho dovuto ricreare la filiale sul telecomando. E sono stato ancora fortunato a farlo abbastanza in fretta in modo che nessuno abbia tirato fuori la storia che ho riscritto.

Credo che sia possibile identificare questo tipo di modifiche e, su richiesta, impedire all'utente di apportarle. C'è forse un'opzione per quello?

In caso contrario, pensi che valga la pena tentare di crearlo? Proveresti a definire con precisione come identificare un "cambiamento pericoloso"?


In un ambiente di lavoro in cui le modifiche errate influiscono su altri programmatori, probabilmente dovresti essere più riluttante a eseguire queste azioni a meno che non sei sicuro che sia qualcosa che dovrebbe funzionare. Anche in questo caso, è necessario verificare che in seguito non sussistano problemi. Immagina che qualche anno fa facessi parte di un team di molti programmatori in cui non ci sarebbero stati problemi a commettere una fonte che non era stata compilata ! Volevo sparargli morto dopo 3 mesi.
Neil,

Sembra ragionevole poterlo rilevare in un hook sul computer remoto e quindi rifiutare le modifiche.
Andrew T Finnell,


Non capisco la tua domanda. La modalità predefinita è sicura. Non ti permetterà di spingere, a meno che non specifichi --force.
Šimon Tóth,

Mi piacerebbe vedere anche qualcosa del genere. Fondamentalmente mi piacerebbe fornire a chi apprende una versione più sicura di Git, probabilmente semplicemente avvolgendo la riga di comando ed esponendo solo le basi: commit, pull, push, roba semplice. Costringili a fare il pieno per qualsiasi cosa in questa pagina: git-scm.com/book/en/Git-Tools-Rewriting-History Git è già un po 'più difficile da imparare rispetto ad altri strumenti per avere un repository locale e remoto a cui pensare - preoccuparsi che si possa riformulare invece del rollback è spaventoso.
Chris Moschini,

Risposte:


5

Questo sembra molto vicino, se non la stessa domanda di Strategia per prevenire o catturare la riscrittura della cronologia di Git

Per riassumere è possibile abilitare

git config --system receive.denyNonFastforwards true

e

git config --system receive.denyDeletes true

Oppure scrivi un hook di ricezione post per rifiutare qualsiasi cosa tu determini sia una riscrittura.


1
Credo denyNonFastforwardssia l'impostazione predefinita (?), Mentre denyDeletesnon lo è. Questi due sono utili, ma sto immaginando una soluzione lato client che mi impedirebbe di fare una cosa commit --amendse non sarei in grado di spingerlo (perché HEAD era già stato spinto).
Kos,

In altre parole: oltre ai meccanismi che consentono di mantenere un telecomando coerente, mi piacerebbe qualcosa che consenta di mantenere un clone "coerente" anche con un telecomando.
Kos,

@Kos Puoi anche creare hook locali
Andrew T Finnell,

C'è un modo per impostare denyNonFastfowardsal truesolo ramo principale? Vorrei che le mie sezioni tematiche potessero essere ridisegnate e spinte forzatamente.
nnyby,

2

No perché fa parte della filosofia di git darti pieno potere e farti gestire quel potere nel modo che desideri.

Se non aderisci a questa filosofia, forse varrebbe la pena passare a Mercurial in quanto consentono di riscrivere la storia ma in modo limitato o, per essere chiaro, riluttante, che ti fa sentire che non è una buona idea.


2
Faccio degli errori. Un meccanismo che mi richiede di confermare esplicitamente ogni volta che sto facendo qualcosa di pericoloso è qualcosa che sembra adattarsi a "gestire il mio potere come voglio". :-) (Anche Git lo fa già in occasioni.)
Kos

2

AFAIK, il modo in cui git risolve questi problemi è che ogni volta che richiedi un'azione del genere, la eseguirà localmente, ma ti informerà che ciò che stai facendo potrebbe avere conseguenze indesiderate. A quel punto, non hai ancora inviato nulla, quindi sei in grado di rivedere il tuo repository locale e possibilmente annullare la pericolosa modifica prima di spingere. Devi prestare attenzione a ciò che Git ti sta dicendo, e è meglio stare attenti quando ripari tali errori.

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.