Per cosa dovrei usare git-worktree?

211

Ho letto il post di Github su git-worktree . Loro scrivono:

Supponiamo che tu stia lavorando in un repository Git su un ramo chiamato feature, quando un utente segnala un bug ad alta urgenza master. Per prima cosa crei un albero di lavoro collegato con un nuovo ramo, hotfixfai il check out rispetto al master [...] Puoi correggere l'errore, inviare hotfix e creare una richiesta pull.

Quando lavoro su un ramo chiamato feature e viene segnalato un bug ad alta urgenza nel master, di solito nascondo tutto ciò su cui sto lavorando e creo un nuovo ramo. Quando ho finito, posso continuare a lavorare. Questo è un modello molto semplice, ho lavorato così per anni.

D'altra parte, l'uso di git-worktree ha i suoi limiti:

Ad esempio, non è consentito avere lo stesso ramo estratto in due alberi di lavoro collegati contemporaneamente, poiché ciò consentirebbe alle modifiche impegnate in un albero di lavoro di rendere l'altro sincronizzato.

Perché dovrei scegliere un flusso di lavoro più complicato per un problema che è già stato risolto?

C'è qualcosa git-worktreeche non si può fare in anticipo e che giustifica questa nuova, complessa funzionalità?

git git-worktree

— awendt
fonte

Una cosa che non puoi nascondere sono i percorsi non uniti, dopo un'unione o un rebase con conflitti.

— Chirlu,

Se lavori con una lingua compilata, lo stashing significa che dovrai ricompilare tutto quando non lo stai facendo.

— mb14

Abbiamo diversi prodotti diversi basati sullo stesso codice sorgente (300 MB) e sto pianificando di combinarli tutti in un unico repository e di utilizzare worktree per mantenere ogni prodotto estratto in una cartella diversa, anziché avere un mucchio di enormi cloni che non rimangono sincronizzati

— endolith il

197

Per me, git worktree è il più grande miglioramento da molto tempo. Sto lavorando allo sviluppo di software aziendale. Lì, è molto comune che devi mantenere versioni precedenti come quelle che hai pubblicato 3 anni fa. Ovviamente hai un ramo per ogni versione in modo da poter passare facilmente ad esso e correggere un bug. Tuttavia, il passaggio è costoso, perché nel frattempo hai completamente ristrutturato il repository e forse hai creato il sistema. Se cambi, il tuo IDE impazzirà nel tentativo di adattare le impostazioni del progetto.

Con worktree puoi evitare quella costante riconfigurazione. Dai un'occhiata a quei vecchi rami in cartelle separate usando worktree. Per ogni filiale, hai un progetto IDE indipendente.

Ovviamente questo avrebbe potuto essere fatto in passato clonando il repository diverse volte e finora questo è stato il mio approccio. Tuttavia, ciò significava anche spreco di spazio hardrive e peggio ancora bisogno di recuperare più volte le stesse modifiche dal repository.

— Sebi
fonte

Non è stato necessario recuperare più volte le stesse modifiche dal repository. Avresti potuto semplicemente copiare la directory .git del primo clone.

— misiu_mp

@ jdk1.0 scusa per la confusione, il commento è stato diretto a misiu_mp

— mxttie il

Come qualcuno che ha utilizzato 2-3 repository altamente replicati in modo da poter costruire un ramo di funzionalità mentre si sviluppa su un altro, ho avuto ogni repository locale come telecomandi degli altri e sono completamente d'accordo con le caratterizzazioni degli aspetti negativi di Sebi (un sacco di recupero e spinta! ) Inoltre, una volta passato al campo di lavoro, mi accorgo che non dovrò più preoccuparmi della divergenza di filiali locali con lo stesso nome (che accade circa una volta ogni 6-10 mesi, quando mi interrompo più volte in un periodo di giorni e finisco lavorando sulla stessa funzione si diramano da più repository, ma dimentica di sincronizzarli di backup ...)

— saggio

@iheanyi - (1). È più veloce se l'IDE mantiene file di dati esterni (come database di indicizzazione) associati a una determinata directory. Se si blocca il contenuto nella stessa directory, ciò invaliderà in genere qualsiasi cache dei dati IDE e dovrà reindicizzare.

— Steve Hollasch,

@iheanyi - (2) Nel tempo, la storia di tutto crescerà molto più grande dei file dell'albero di lavoro in un dato punto. La storia di tutto == la .gitdirectory. Con molti cloni locali dall'upstream, si hanno molte copie locali dello stesso database, poiché ogni clone ha il proprio .gitdatabase. Con molti alberi di lavoro locali, ogni albero utilizza lo stesso .gitdatabase. Sì, se disponi di cloni locali del tuo gruppo di lavoro locale, Git collegherà in modo rigido molti dei contenuti .git, ma non su Windows.

— Steve Hollasch,