Tirare per un altro ramo Git senza cambiare

55

siamo recentemente passati da SVN a Git e allo stesso tempo abbiamo messo i nostri sistemi live in controllo versione (anziché checkout locale e copia file per vivere).

Nel progetto a cui sono assegnato accediamo tutti allo stesso repository e per rendere effettivi i cambiamenti ci siamo appena git pullarrivati. Ciò causa problemi perché i nostri webdesigner introducono modifiche nel VCS che non dovrebbero essere ancora attive ma dovrebbero essere nell'ambiente di test Web.

Quando uno degli sviluppatori entra ora in live riceve tutte le modifiche (possibilmente incompiute).

Ho pensato di passare dal vivo a un ramo extra e unire ciò che è cambiato, ma a causa della mia mancanza di conoscenza git non ho idea di come.

La mia idea è:

Crea una nuova filiale in live ( git branch live).
Ogni volta che qualcosa deve andare in diretta
- Tirare le modifiche in master (come git checkout master; git pull; git checkout live:)
- git merge master

Il problema è che passare al master o trascinare tutto direttamente nel sistema live causerebbe problemi, quindi preferirei evitare questo.

C'è un modo per farlo o c'è un modo migliore per gestire il sistema Live (tranne che per addestrare i webbies a non spingere roba incompiuta).

git

— Morfildur
fonte

git pull --allper impostazione predefinita non trascinerà il master in live, tirerà il master e lo unirà con master e (se esistente sul server) tirerà live per unire in live. Hai provato?

— Tobias Kienzler,

Il tuo problema è causato da un file che non era sotto il controllo della versione prima di diramarsi dal vivo e aggiunto da git dopo essere stato modificato in seguito? Questo è quello che mi è successo prima, di solito dovrebbe essere sufficiente rinominare temporaneamente quel file o, se non è necessario in tempo reale , utilizzare git checkout -fper ignorare il problema, ma fare un backup!

— Tobias Kienzler,

1

correlato: stackoverflow.com/questions/3216360/...

— Ciro Santilli新疆改造中心法轮功六四事件

21

Puoi usarlo git stashprima di estrarre master e tirare, e dopo aver verificato di nuovo live usa git stash pop(o se il tuo git è più vecchio, git stash applye git stash clearsupponendo di non aver nascosto altro)

— Tobias Kienzler
fonte

6

git pull --allrecupererà tutti i telecomandi, ma proverà comunque a unire un ramo (o il ramo predefinito) anche nel ramo corrente.

— mipadi,

@mipadi sì, ma solo il ramo attuale in se stesso senza cercare di controllare il master e causare il conflitto, no?

— Tobias Kienzler,

Unirà qualsiasi ramo configurato per essere automaticamente unito al ramo corrente (se tale ramo è configurato).

— mipadi,

1

@Superole È documentato come "recupera tutti i telecomandi", che include non solo più repository, ma anche rami. Sebbene con il senno di poi, git fetch --allavrebbe potuto essere una risposta migliore

— Tobias Kienzler il

2

@TobiasKienzler Indica solo a git di recuperare da tutti i telecomandi configurati. Il caso più comune è avere solo un'origine denominata remota. SE ti capita di avere più di un telecomando con lo stesso ramo del tuo attuale e non hanno una relazione di avanzamento rapido l'uno con l'altro, ALLORA usando l' --allopzione ti darà una fusione di polpo delle diverse versioni del ramo nella corrente ! Quindi il mio consiglio è di stare alla larga, a --allmeno che non sia quello che stai cercando, perché nella maggior parte degli altri casi non ti darà nulla.

— Superole,

74

Sono stato in grado di estrarre le modifiche da origin/masterin mastermentre lavoravo in un altro ramo usando questo comando:

git fetch origin master:master

— Jeff B
fonte

6

Eccezionale! Esattamente quello che stavo cercando - questo deve essere documentato in modo molto più evidente ...

— Markus Shepherd

2

Puoi trovare la documentazione qui: git-scm.com/docs/git-fetch#_examples

— c1moore

fetch! =pull

— D. Kovács il

5

Risolvi prima il problema. Non dovrebbero spingere verso un ramo verso il quale non hanno attività commerciali.

Quello che sembra chiedere sarebbe qualcosa di simile

git checkout live
git pull origin master

Ciò tenterà di unire il master remoto e il tuo ramo attivo.

— Josh K
fonte

Il problema è che al momento abbiamo un solo ramo e non sarà davvero possibile cambiarlo poiché tutti sono troppo abituati a SVN e non sono disposti a imparare i vantaggi di qualcosa di nuovo. Sarà possibile creare un nuovo ramo solo nella directory live. Unire il master remoto al ramo live è ciò che voglio evitare in quanto non posso impedire a nessuno di inviare codice di debug, funzioni incomplete, errori di sintassi e qualsiasi altra cosa al master (dopo tutto, sono solo lo sviluppatore junior). Grazie per il tuo suggerimento però.

— Morfildur,

2

@dbeme: potresti usare tarball e patch. ;) A meno che non siano disposti a imparare git (e non è affatto difficile ramificarsi e fondersi) si avranno problemi.

— Josh K,

0

Ti consiglio di creare un repository git di prova che tutti possano impegnare. Tutti i repository, incluso il sito Web live, saranno cloni del repository di prova. In questo modo, chiunque può spingere ai test senza toccare il sito Web live. Quando qualcuno deve aggiornare il sito live, è possibile estrarre il sito live dal repository di test git. Questo flusso di lavoro è abbastanza simile a SVN. Per una maggiore flessibilità, ti consiglio di usare il ramo "live" che descrivi.

Per riassumere, il repository git di tutti è un clone del repository di prova. Anche il sito di produzione live è solo un clone del repository di test. In alternativa, i test potrebbero essere un clone di produzioni live in modo che una "spinta git" si sposta sempre verso la produzione.

Altre opzioni tra cui l'aggiunta del ramo "live" a questa disposizione o l'inclusione di un repository "di gestione temporanea" tra test e produzione. Per maggiore sicurezza, raccomando di limitare l'accesso al repository live git e di forzare le persone a utilizzare uno script protetto che attiri la produzione live.

— edgester
fonte