C'è un modo con Git per fare in futuro che le unioni ignorino la differenza del numero di versione in un file pom tra le filiali?

Question

Il mio team sta pianificando di passare da Perforce a Git e sto cercando di trovare un modo per far sì che Git ignori le differenze della versione pom tra i rami. Funziona bene in Perforce e non ho alcuna fortuna nel riprodurre il comportamento con Git.

Qui sono i miei passi:

1. ramo Checkout genitore

   ndeckard@ws /c/dev/proj/testgit (master) 
   $ git checkout release/1.0 
   Switched to branch 'release/1.0' 
   Your branch is up-to-date with 'origin/release/1.0'. 
   

2. Crea ramo bambino da esso

   ndeckard@ws /c/dev/proj/testgit (release/1.0) 
   $ git branch branch/FEA-650 
   

3. passare alla nuova filiale

   ndeckard@ws /c/dev/proj/testgit (release/1.0) 
   $ git checkout branch/FEA-650 
   Switched to branch 'branch/FEA-650' 
   

4. Aggiornamento versione ramo bambino pom

   <version>1.0.0-FEA-650-SNAPSHOT</version> 
   

5. Aggiungi e commettere

   ndeckard@ws /c/dev/proj/testgit (branch/FEA-650) 
   $ git status 
   On branch branch/FEA-650 
   Changes not staged for commit: 
       (use "git add <file>..." to update what will be committed) 
       (use "git checkout -- <file>..." to discard changes in working directory) 
   
        modified: pom.xml 
   
   no changes added to commit (use "git add" and/or "git commit -a") 
   
   ndeckard@ws /c/dev/proj/testgit (branch/FEA-650) 
   $ git add pom.xml 
   
   ndeckard@ws /c/dev/proj/testgit (branch/FEA-650) 
   $ git commit -m "set feature branch pom version" 
   [branch/FEA-650 59e156e] set feature branch pom version 
   1 file changed, 1 insertion(+), 1 deletion(-) 
   

6. Tornate al ramo genitore

   ndeckard@ws /c/dev/proj/testgit (branch/FEA-650) 
   $ git checkout release/1.0 
   Switched to branch 'release/1.0' 
   Your branch is up-to-date with 'origin/release/1.0'. 
   

7. Unisci ramo bambino in auto- genitore accettare la versione del ramo padre (usando la strategia di fusione “nostro”)

   ndeckard@ws /c/dev/proj/testgit (release/1.0) 
   $ git merge branch/FEA-650 -s ours 
   Merge made by the 'ours' strategy. 
   

8. Tentativo 2 ° fusione di bambino nel genitore (già up-to-date.) Buona. Questo è quello che voglio

   ndeckard@ws /c/dev/proj/testgit (release/1.0) 
   $ git merge branch/FEA-650 
   Already up-to-date. 
   

9. Checkout bambino e si fondono genitore in figlio (in avanti velocemente e attacca le diramazioni principali pom versione sul bambino). Non bene. Ho bisogno di dire "già up-to-date", come sopra e mantenere la versione ramo bambino pom come già è sul ramo bambino

   ndeckard@ws /c/dev/proj/testgit (release/1.0) 
   $ git checkout branch/FEA-650 
   Switched to branch 'branch/FEA-650' 
   
   ndeckard@ws /c/dev/proj/testgit (branch/FEA-650) 
   $ git merge release/1.0 
   Updating 59e156e..2f3a2a0 
   Fast-forward 
   pom.xml | 2 +- 
   1 file changed, 1 insertion(+), 1 deletion(-) 
   

Dopo il punto 7, vorrei si fonde in entrambe le direzione tra genitore e figlio per dire (Già aggiornato.)

C'è un modo con Git per rendere le future unioni ignora la differenza del numero di versione nel file pom tra le filiali?

Answer 1

Probabilmente sarebbe oneroso farlo per ogni fusione, ma ecco un'idea.

git merge --no-ff --no-commit <other-branch>

git checkout HEAD -- pom.xml

Il primo comando consente di effettuare modifiche di contenuto prima della fusione completata, anche se non ce ne sono fondono conflitti. Il secondo sostituisce il pom.xml con qualunque cosa fosse nel commit precedente del ramo corrente, ignorando efficacemente pom.xml dall'altro ramo.

Utilizzare la strategia di unione - il nostro è problematico se ci sono conflitti in qualsiasi file diverso da pom.xml, quindi sarei stanco di usarlo per questo scopo.

Answer 2

Il mio primo pensiero è di automatizzare i numeri di versione POM esternando parzialmente il calcolo POM <version>, vedere più in basso nella risposta. Se non vuoi farlo, devi rivalutare il tuo flusso di lavoro Git.

L'unione a due vie, in master e quindi di nuovo nel ramo di funzione causa problemi. Il tuo git merge branch/FEA-650 -s ours utilizzando la nostra strategia didice Git che avete integrato tutti i depositi e le modifiche dal ramo di caratteristica in master, compreso il vostro pom.xml cambio di versione, che si perde, con master conservando la sua versione. Il ramo principale ora considera l'elemento HEAD del ramo feature come un antenato comune (si tratta di un commit genitore nell'unione), quindi quando lo unisci al ramo della funzione, Git dice "tutto è stato risolto quando ti sei unito al master, non ci sono cambia ... avanti veloce ".

La semplice risposta è che si dovrebbe ri-ramo di un nuovo ramo di caratteristica dopo la fusione da padroneggiare, dando il vostro ramo di caratteristica un antenato nuova/in seguito più giovane comune, allora avete bisogno di riprodurre in qualche modo il tuo POM <version> cambiamento. Non si dovrebbe continuare a lavorare sul ramo della funzione originale, poiché è stato unito. Per raccogliere nuove modifiche dal master, dovresti cambiare ramo. Sembra esserci qualche implicazione nel fatto che potresti aver lasciato delle modifiche sul ramo della funzione non raggruppate con il master, altrimenti non ne avresti più bisogno e potresti cambiare ramo, o potrebbe essere semplicemente il commit di cambiamento <version> che ti interessa.

C'è un numero qualsiasi di modi per semplificare/accelerare/automatizzare la gestione del numero di versione su ramificazioni, dall'esternalizzazione (vedi sotto) a cherry-picking da un ramo segnaposto, usando un plugin Maven es. Versions Maven Plugin.

risposta originale

altro approccio sarebbe quello di calcolare esternamente la finale/efficace <version> fuori il file POM, in base ai metadati filiale o altro ingresso dal CI. Questo è un po 'complicato da fare a Maven senza pre-munging pom.xml dopo il checkout, ma dai uno sguardo allo Maven External Version Plugin.

Si aggancia nel ciclo di vita Maven e creerà un file pom.xml.new-version al volo (che è possibile .gitignore), in modo dinamico, sostituendo tutto o in parte il numero di versione, in base a ciò che si fornisce - un nome di funzione-ramo, git commettere hash ecc

build/distribuire il plugin e aggiungerlo al tuo POM:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-external-version-plugin</artifactId> 
    <version>0.1.0-SNAPSHOT</version> 
    <extensions>true</extensions> 
    <configuration> 
     <strategy hint="sysprop"/> 
    </configuration> 
</plugin> 

... poi essere creativi con sostituendo la versione-string, ad esempio è possibile:

mvn install -Dexternal.version-qualifier=$(git symbolic-ref --short HEAD| sed s_^master\$__) 

... che cambierà 1.2.3-SNAPSHOT a 1.2.3-FEA-650-SNAPSHOT se il ramo Git attuale estratto è FEA-650. Potrebbe essere necessario prendere in considerazione la sostituzione di / con - nella strategia di denominazione delle filiali, a seconda di cosa ne pensa Maven (trovo che lo / s confonda, ma sono solo io) o modificare lo sed di conseguenza.

Nel peggiore dei casi ciò consentirebbe di rimuovere il numero di versione dal tuo POM, in modo che altre modifiche POM possano essere unite in modo sicuro e note come non correlate a numero di versione - se necessario è possibile mantenere i numeri di versione in un altro file , utilizzando un plug-in Maven Properties per caricarli e, se necessario, sostituire l'intero numero di versione.