2013-06-24 15 views
8

Ho un repository Git ospitato su bitbucket che ha la seguente struttura di directory:Tirando remoto nella sottodirectory

/Automation 
/Website 
/Website/ <-- [WebsiteFilesGoHere] 
/Dependencies 
/WebServices 

Abbiamo un fornitore che sta costruendo la parte /Website di soluzione.

Hanno un pronti contro termine che assomiglia a questo

/ <-- [WebsiteFilesGoHere] 

Qual è il modo migliore per tirare loro repo nella nostra sottocartella, e quindi in grado di spingere di nuovo in un secondo momento?

UPDATE: Vale la pena ricordare che entrambi i repos hanno file nella cartella corrente "/ Sito web" senza conoscersi l'un l'altro.

UPDATE 2: Questo è anche un repo Git basato su Windows, che è condiviso tra un numero di sviluppatori (in modo da evitare qualsiasi configurazione di macchina locale sarebbe grande).

+2

vedere 'man git-submodule' – Jokester

+0

Data la sezione di aggiornamento, forse un vero sottomodulo da qualche altra parte e alcuni symlink nel repository corrente? – Jokester

+0

Puoi darmi un po 'di aiuto? Sto giocando con il supporto per i sottomodelli git. colpire un po 'di un muro di mattoni mentre la cartella 'Website' esiste già. Prima di ramificare/soffiare via la cartella per aggiungere il sottomodulo, voglio solo assicurarmi che stia facendo la cosa giusta. – Doug

risposta

1

Suggerisci spesso meglio usare Subtrees invece di moduli

Una buona corsa attraverso dei benefici qui:

http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/

Ci sono diversi motivi per cui si potrebbe trovare sottostruttura meglio utilizzare:

La gestione di un flusso di lavoro semplice è semplice.

Le versioni precedenti di git sono supportate (anche prima della v1.5.2).

Il codice del sottoprogetto è disponibile subito dopo aver completato il clone del super progetto.

La sottostruttura non richiede agli utenti del repository di apprendere nulla di nuovo, possono ignorare il fatto che si utilizza la sottostruttura per gestire le dipendenze.

sottostruttura non aggiunge nuovi file di metadati come sottomoduli doe (cioè .gitmodule).

Il contenuto del modulo può essere modificato senza avere una copia separata del repository della dipendenza da qualche altra parte.

A mio parere gli svantaggi sono accettabili:

È necessario conoscere una nuova strategia di fusione (vale a dire sotto-albero).

Il codice contributivo di nuovo a monte per i sottoprogetti è leggermente più complicato.

La responsabilità di non mescolare il codice di super e di sottoprogetti in commit è responsabilità dell'utente.

5

C'è un modo per portare in un repository remoto senza l'utilizzo di moduli o sottostrutture, anche se questo repository è completamente estraneo al tuo e ha indici contrastanti.

In primo luogo, aggiungere tale repository come uno dei telecomandi nello .git/config.Ad esempio, supponiamo che tu voglia introdurre la libreria Gruff di Zaldor da Github. Questi nomi sono del tutto fittizi:

[remote "gruff-upstream"] 
fetch = +refs/heads/*:refs/remotes/gruff/* 
url = https://github.com/zaldor/gruff.git 

ora si può fare un git fetch gruff-upstream per ottenere tutti gli oggetti. Ora puoi vedere le filiali disponibili nei progetti gruff.

$ git branch -r 
gruff/experimental-hack 
gruff/master 
origin/master 

Le due linee sono gruffgruff 's rami. origin/master è la nostra origine. I nomi si scontrano: gruff ha un master e abbiamo anche master. Non importa: possiamo dare a gruff/master un nome di filiale locale diverso.

$ git branch -t gruff-master gruff/master 
Branch gruff-master set up to track remote branch master from gruff-upstream. 

Ora, se noi git checkout gruff-master, tutti i nostri file git-rintracciato scomparirà, sostituito dalla copia di lavoro gruff:

$ git checkout gruff-master 

Ora noi siamo in grado di governare questa filiale gruff-master un po '. Per esempio, siamo in grado di spostare tutti i file in una sottodirectory, rimuovere i file indesiderati e quali:

$ mkdir gruff 
$ git mv ...files... gruff 
$ git commit -a -m "moving gruff stuff to gruff/ subdir" 

Successivamente, tornare al nostro master. file burbero scompaiono, e le nostre file sono tornati:

$ git checkout master 

Ora possiamo portare alcuni file dal gruff nel nostro master:

$ git checkout gruff-master -- gruff/file1 gruff/file2 ... 

Questi file si materializzano nella nostra copia di lavoro e vengono aggiunti al nostro indice:

$ git checkout 
A gruff/file1 
A gruff/file2 
... 

possiamo solo commettere questi nella nostra master ora.

Quando l'upstream gruff pubblica nuove versioni dei file, possiamo passare al nostro gruff-branch e pull. Risolvi le nuove modifiche contro la nostra pulizia e commit. Tornando al nostro master, possiamo selezionare il nuovo aggiornamento dal nostro ramo di tracciamento locale gruff-master.

Sì, questo è fondamentalmente l'utilizzo di Git come strumento di correzione glorificato. Il materiale da gruff-master raccolto in master non ha ascendenza; sembra proprio come i file aggiunti. Tuttavia, è meglio di niente e in molti modi meno ingombrante di sottostrutture o moduli.

Problemi correlati