2013-07-13 17 views
5

Sto lavorando a un progetto open source. Ora ho terminato alcune patch che sono rilevanti per il business aziendale e non posso spingere queste patch a monte.Come gestire le patch di progetti open source che non possono essere trasferite a monte?

Quindi devo tenere queste patch sul mio repository git locale. Devo estrarre le nuove patch da upstream e risolvere i conflitti con le mie patch.

Qualcuno ha la mia esperienza simile e come lavorarci comodamente?

Aggiornamento: Proprio come se ho diverse patch non posso essere accettate da Linux Kernel perché queste patch sono ostili al kernel. Devo fare una compilazione quotidiana del kernel e non voglio scrivere a mano ogni giorno. C'è qualche strumento per aiutarmi?

+0

Perché non si può spingere? hai una descrizione di errore o qualcosa del genere? –

+0

Il progetto è su GitHub? –

+0

Se il progetto è open source, puoi dirci quale progetto è? Forse possiamo scoprire come quel particolare progetto vuole gestire le richieste. –

risposta

1

primo luogo prima di apportare modifiche al progetto-

1. create a branch 
    2. Change to that branch for any changes you make 
    3. To pull the new patches from the upstream revert back to the master branch and then git pull. 

I comandi per creare il ramo e cambiamento sono i seguenti

1. $ git branch <branch name>   // To create a new branch 
2. $ git checkout <branch name>   // To change to the branch 
3. $ git checkout master    // To change to the master branch 
+0

Esiste un sistema di gestione con cui gestire ? Proprio come se avessi un sacco di patch e diversi progetti, sarà necessario molto tempo per mantenere aggiornato il mio repository locale. –

+0

A partire da ora non utilizzo alcun sistema di gestione. Ma come hai giustamente menzionato, c'è bisogno di farlo. Aggiornerò una volta trovato uno strumento adatto che aiuti a lavorare su diversi progetti –

-1

sto lavorando su un progetto open source. Ora ho terminato alcune patch che sono rilevanti per il business aziendale e non posso spingere queste patch a monte.

Se stai collaborando a un progetto in Git, specialmente se è open source, la gente probabilmente non ti lascerà solo spingere tutto ciò che vuoi sul repository upstream. Probabilmente vorrai inviare le tue modifiche in una richiesta di pull o inviare per email le patch a uno dei project manager.

Si può leggere di più su collaborare con altre persone in Git da questi Pro Git capitoli:

  1. Distributed Workflows
  2. Contributing to a Project

Se siete interessati, potete anche leggere su how GitHub uses pull requests.

4

Sono un po 'sorpreso che le risposte finora non sembrano tener conto di due cose:

  1. Non tutte le modifiche apportate dai programmatori è destinato a favore o adatto per la presentazione di un progetto open source.
  2. Anche se è presente un aggiornamento del repository mentre si lavora sul codice, molto spesso si desidera unire tali modifiche nella propria copia di lavoro.

La cosa buona è che dal momento che si sta lavorando con una versione decente, il software di controllo di solito non è così difficile da fare ciò di cui si ha bisogno. Sono un ragazzo di sovversione (a causa della politica aziendale) quindi non so specificamente di GIT ma dopo aver letto this wiki article, sembra più o meno lo stesso accordo. Non è necessario applicare nuovamente le patch finché si inseriscono i file nel repository locale. È possibile aggiornare la copia locale con le patch già applicate!

Il codice personalizzato probabilmente tocca una frazione molto piccola del codice del repository. È probabile che la maggior parte delle modifiche nel repository non tocchino lo stesso codice che hai toccato.Dovrai semplicemente usare il comando git pull per scaricare tutto il codice aggiornato. Quando le sezioni che hai toccato sono cambiate nel repository, git farà il meglio per unire queste modifiche. L'unica volta che devi modificare i file manualmente è che Git rileva un conflitto che non è in grado di risolvere. L'articolo che ho menzionato, in precedenza parla di questo.

È possibile utilizzare l'editor di testo preferito, ma in questo caso è molto conveniente utilizzare uno strumento di unione a 3 vie. Meld è uno di questi strumenti per Linux ma sono sicuro che ce ne sono molti là fuori.

1

Ecco un possibile flusso di lavoro.

configurazione iniziale

git clone --origin 'upstream' http://example.com/project.git 
cd project 
git checkout master 
git checkout -b patched 
# make changes 
git add --all 
git commit -m 'internal patches' 

nuovi cambiamenti a monte

git checkout master 
git pull upstream 
git checkout patched 
git rebase master 

Riferimenti: