Quindi quale è meglio, usando git-p4 o semplicemente facendo scorrere una directory .git nella directory di lavoro e dovendo per forza ignorarla?

Question

So che questo ha comeup prima, ma c'era poco in termini di esperienze personali giorno per giorno nei post che ho visto. Solo un paio di risposte. Mi piacerebbe sentire gente che usa git-p4, o ha usato git "sotto le coperte" in un repository Perforce, o preferibilmente entrambi.
E per coloro che usano solo git sotto un altro controllo di versione, mi piacerebbe sapere come ti occupi di notificare il controllo della versione principale delle modifiche. In particolare, con git/perforce, quando hai finito e sei pronto a commettere le modifiche al server di perforce, come gestisci il fatto di dire per forza quali modifiche sono state apportate?
Ho esaminato i ganci post-commit con git, ma mi piacerebbe sentire altre idee.

Answer 1

Ho usato git-p4 al lavoro. È un bridge bidirezionale, quindi se vuoi usare git e poi riconvertire il tuo commit locale in p4, è un bel modo per andare. Tuttavia, la nostra politica dell'ufficio aveva una cultura di un piccolo numero di commit massicci piuttosto che molti piccoli, quindi ho dovuto rebase tutte le modifiche in una singola patch prima di inviarla nuovamente in p4. Mi sarebbe piaciuto mantenere la storia locale a grana fine ma riprendere in un colpo solo ma non riuscirei mai a gestirlo.

---

notifica di modifica Apropos. git-p4 crea patch per ogni check-in dal tuo ultimo e li invia come changeset separati. Questo tipo rispecchia la cronologia del ramo principale su cui stai lavorando nel tuo repository git.

Answer 2

Io uso git con TFS e ho scelto di andare con l'opzione 2: far scorrere la directory .git e TFS ignorarlo. Lo faccio per la stessa ragione per cui @Noufal lo fa, qui abbiamo una cultura di "un grosso impegno" rispetto alle decine di piccoli commit che faccio in Git. Dal momento che mi sto impegnando solo su TFS una o due volte al giorno, non vale la pena di scherzare con ganci post-commit o rebases o altro.

Answer 3

Immagino che dipenda davvero dal layout del tuo repository perforce - se stai lavorando su una sezione relativamente piccola di esso, allora probabilmente andrei a far cadere dritta la directory .git. È il percorso minimo di resistenza di gran lunga e l'ho usato con successo su progetti più piccoli.

Detto questo, ho faticato con questo approccio su repository di grandi dimensioni, probabilmente tanto per il flusso di lavoro in cui lavoro come il sovraccarico di gestione di tutto ciò. Devo ancora dare un'occhiata a git-p4, ma è qualcosa che mi interessa indagare ulteriormente.

Answer 4

Il modo in cui lo faccio è avere un ramo master e rami funzione in git, e quindi usare git diff --name-only master su un ramo di funzione per capire quali file sono cambiato per una particolare caratteristica. Quindi controllo questi file in un elenco di modifiche di Perforce e lo invio.

... beh, più o meno ... :) In pratica, utilizziamo Code Collaborator per le revisioni del codice, quindi controllo i file qualche volta tra l'inizio del lavoro sulla funzione e l'invio dei file per la revisione del codice (non importa molto quando). Poi controllo prima della revisione del codice che ho tutti i file che dovrei avere usando il comando git sopra. (In realtà, dato che sono paranoico, ora faccio un git clean -xdf nella mia directory di origine e faccio un "Riconciliazione lavoro offline" di Perforce per ricontrollare ciò che sto per inviare, quindi eseguo una ricostruzione completa dell'intero progetto. Rompere la build è imbarazzante, dopotutto.) Una volta che tutte le revisioni sono state fatte, ho appena inviato l'elenco delle modifiche come di consueto.

E 'un po' un faff, in realtà, ma non è così male, ora che ho sono abituato ad esso - ed è molto meglio di un semplice utilizzando Perforce con commit massicce, ed efficacemente a lavorare senza alcun tipo di controllo di versione per giorni alla volta :)