2009-09-11 12 views
6

Sono novizio in Git.Mantain vecchie versioni senza creare filiali di lunga durata

Ho letto: "Pro Git: Mantenere un progetto" (libro) e Git: Documentazione/howto/mantenere-git.txt

Domanda difficile per me: come mantenere le vecchie versioni senza creando rami separati a vita lunga. In altre parole, sono interessato a lavorare con un ramo "maint" nel progetto Git.

In questo esempio (la fusione con i rami argomento e l'integrazione dei contributori delle patch non viene mostrata, anche altri rami di "successivo", "pu" non vengono visualizzati qui).

Queste immagini possono essere visualizzate anche at here.

  +--master 
      | 
      +--maint 
      | 
    (c1)->(c2) 
      | 
      +--tag : feature-release v1.0 

prossima volta:

tag:feature-rel v1.0--+     +--master 
         |     | 
       (c1)->(c2)->(c)->(c)->(c)->(c) 
         | 
         +->(c)->(c)->(c) 
            | 
            +--maint 
            | 
            +--tag:maint-rel v1.0.1 

successivo, come descritto in "mantenere-git.txt", eseguire:

$ git checkout master 
$ git merge maint 

Risultato:

tag:feature-rel v1.0--+       +--master 
         |       | 
       (c1)->(c2)->(c)->(c)->(c)->(c)->(c100) 
         |      /
         +->(c)->(c)->(c50)-----' 
            | 
            +--maint 
            | 
            +--tag:maint-rel v1.0.1 

prossima volta :

       +--master 
           | 
           +--tag:feature-rel v2.0 
           | 
    ...->(c)->(c100)->(c101)->(c102) 
      /
...->(c50)---' 
     | 
     +--maint 
     | 
     +--tag:maint-rel v1.0.1 

E a questo punto ho alcune domande:

  1. Cosa a che fare con la "maint" ramo? Capisco che il puntatore "maint" debba essere spostato nella stessa posizione del "master"? Come ?
  2. Successivamente come fare un fork di un ramo "maint" dal ramo "master"?
  3. Se appare una patch (trascorsi molto tempo, ad esempio, la versione corrente v10.0) per il vecchio "tag: maint-rel v1.0.1", come integrarlo nel "maint" e in "maestro"?

Grazie.

risposta

3

come mantenere le vecchie versioni senza creare un separato rami longevi

rami di manutenzione sono spesso fatto per il rilascio, e di lunga durata, in quanto servono a correggere bug specifico per quella release, e non tutto deve essere ricollegato allo sviluppo attuale.

1/Cosa fare del ramo "maint"? Capisco che il puntatore "maint" debba essere spostato nella stessa posizione del "master"? Come ?

Non sono sicuro del motivo per cui dovresti riutilizzare il comando qui. un rebase non funzionerebbe.
può essere un

$ git checkout maint 
$ git reset --merge c102 

Poiche 'maint' era già fusa in maestro, credo che questo reset non sarebbe aggiornare uno dei file più recenti in master.

ho appena provato:

alt text http://img188.imageshack.us/img188/4425/resetmerge.png

Lo fa muovere la testa di 'maint', senza toccare alcun file in master.

2/Successivamente come fare una biforcazione di un ramo 'maint' dal ramo 'master'?

Bene il reset avrebbe dovuto spostare la testa di 'maint' per l'attuale sviluppo: se C102 è la v2, tutto ciò che serve è alla cassa 'maint', e si dovrebbe sborsare subito.

che vi darà:

alt text http://img36.imageshack.us/img36/91/resetmerge2.png

3/se appare una patch (intercorrere un tempo molto lungo, per esempio, l'attuale v10.0 funzione-release) per il tag vecchio" : maint-rel v1.0.1 ", come integrarlo nel" maint "e in" master "?

C'è necessario creare un "ramo di manutenzione denominato":

$ git checkout -b maint-1.0 c50 
$ # work on patch 
$ git checkout maint 
$ git cherry-pick ... # only merge what you need in maint 
$ git checkout master 
$ git cherry-pick ... # only merge what you need in maint 

Nota: è possibile non fondere la stessa cosa in maint (che possono ancora bisogno di qualche parte della correzione fatta in maint -1.0) e master (che potrebbe essersi evoluto così tanto che la maggior parte della patch non è più rilevante)

Problemi correlati