2012-02-24 4 views
31

Mam projekt z oddziałem dev i oddziałem produkcyjnym. Ostatnio pracowałem nad nowym zestawem funkcji w dev, więc nie połączyłem się z produkcją przez około dwa tygodnie. W międzyczasie jednak pojawiły się błędy, które należało naprawić w produkcji.Jaki jest najlepszy sposób na wymuszenie scalenia w git?

W większości przypadków udało mi się wprowadzić poprawki w dev i cherry-pick je do produkcji. Czasami jednak musiałem ręcznie naprawiać produkcję, ponieważ poprawki różniły się zasadniczo w obu oddziałach. Chodzi o to, że dwie gałęzie oddzieliły się nieco, odkąd się rozdzieliły.

Teraz chcę popchnąć całe dev do produkcji. Nie dbam o to, by zachować jakiekolwiek zatwierdzenia w produkcji od momentu podziału, chcę tylko, żeby produkcja wyglądała dokładnie tak jak dev. [EDIT: Chcę, aby produkcja wyglądała dokładnie tak jak dev od podziału, ale nie chcę przepisywać historii przed podziałem]. Jednak gdy próbuję scalić, otrzymuję dziesiątki konfliktów, których wolałbym nie naprawiać dłoń.

Jaki jest najlepszy sposób zmuszenia do scalenia w git? Czy mogę przywrócić zmiany produkcyjne z powrotem do podziału, a następnie po prostu szybko przejść do działu dev?

Odpowiedz

26

można po prostu wcisnąć swój oddział dev na produkcji repo oddziału głównego:

git push --force upstream-remote dev:production 

upstream-remote może być tylko origin jeśli jesteś na domyślny klon.

Aktualizacja dla mod'ed pytanie:

Prawdopodobnie nie chcą revert w sensie git ale tak, że mniej więcej to, co chcesz robić. Coś jak

git checkout -b merge <split hash> 
git merge dev 
git push --force origin merge:production 

< podzielonym hash > był ostatni popełnić na produkcji, które chcesz zachować.

+0

Hmmm, rzeczywiście myślę misspoke kiedy powiedziałem, że chciał „produkcja wyglądać dokładnie jak dev.” Chodziło mi o to, że chciałbym, aby gałąź wyglądała dokładnie tak jak dev * od podziału *. Chodzi o to, że chcę, aby cała firma działała od momentu podziału na produkcję, nie przejmując się produkcyjnymi zobowiązaniami. Nie chcę jednak przepisywać historii * przed * podziałem, co brzmi tak, jak zrobiłoby to twoje rozwiązanie. –

+1

Dwie gałęzie były takie same w podziale? Tak to brzmi. Jeśli tak, to oni mieli taką samą historię przed podziałem, więc nic nie tracisz. – smparkes

+0

Historia oddziału nie była taka sama. Chyba ciągle mylę. Dwa tygodnie temu wszystkie pliki były identyczne, a ja po prostu połączyłem się z dev do produkcji w czysty sposób. Potem zaczęli się rozchodzić - to właśnie nazywałem podziałem. Ale historia dwóch oddziałów jest inna. –

-4

Ten połączą swoje newBranch w istniejących baseBranch

git checkout <baseBranch> // checkout baseBranch 
git merge -s ours <newBranch> // this will simply merge newBranch in baseBranch 
git rm -rf . 
git checkout newBranch -- . 
+0

Czytelnik powinien zauważyć, że '-s ours' nadpisze istniejącą pracę, podczas gdy' -X ours' zezwoli na sprzeczne różnice do scalenia.'-s ours' sprawi, że gałąź będzie miała ten sam stan co inny, podczas gdy' -X nasz' nie po prostu zwinie gałąź. Nie poprawiam proponowanej odpowiedzi, ale wskazuję ważny szczegół. – haleonj