Jak przetestować scalanie bez wcześniejszego scalania

166

Czy istnieje sposób symulacji a git mergemiędzy dwoma gałęziami, bieżącą gałęzią roboczą i główną, ale bez wprowadzania jakichkolwiek zmian?

Często mam konflikty, kiedy muszę zrobić plik git merge. Czy istnieje sposób, aby najpierw zasymulować scalanie?

git merge

— zasiłek doug
źródło

2

zobacz także stackoverflow.com/questions/501407/…

— Andre Holzner

1

Możliwy duplikat Czy istnieje opcja git-merge --dry-run?

— Tin Man

132

Nie sądzę, aby istniał sposób na symulowanie tego, co się stanie, dopóki nie spróbujesz scalenia. Jeśli jednak upewnisz się, że dane wyjściowe programu git statussą puste przed scaleniem, możesz po prostu go wypróbować. Jeśli wystąpią konflikty, możesz natychmiast wrócić do stanu, w którym byłeś wcześniej:

git reset --merge

Od wersji Git 1.7.4 możesz również przerwać scalanie, wykonując:

git merge --abort

(Jak wyjaśnia komunikat dotyczący zatwierdzenia, który dodał tę opcję , dodano to w celu zachowania spójności z git rebase --aborti tak dalej).

— Mark Longair
źródło

4

@ Amber odpowiada dokładnie na pytanie „jak zasymulować scalanie”. używanie --no-commitjest moim zdaniem dużo łatwiejsze

— samirahmed

14

@samirahmed: @Amber odpowiedział na pytanie bardziej dosłownie, oczywiście, chociaż --no-commitnadal zmieniasz indeks i drzewo robocze, co nie jest dokładnie „bez wprowadzania żadnych zmian” :) Chodzi mi o to, że kiedy ludzie pytają tego rodzaju pytanie, to generalnie dlatego, że nie są świadomi, że najlepszym sposobem, aby zobaczyć, jak przebiegnie scalanie, jest po prostu spróbować scalenia , często dlatego, że nie są świadomi tego, jak łatwo jest wrócić do stanu, w którym byli wcześniej gdyby okazały się problemy.

— Mark Longair

2

Nie wiem, czy to zostało dodane w nowszej wersji gita, ale w dokumentacji (1.8.4) jest napisane " git merge --abortjest równoważne z git reset --mergekiedy MERGE_HEADjest obecne", więc cokolwiek jest łatwiejsze do zapamiętania :)

— Samuel Meacham

@SamuelMeacham: dzięki za zwrócenie uwagi - zostało wprowadzone w wersji 1.7.4. Zaktualizowałem odpowiedź o to. Dzięki!

— Mark Longair

Ta sugestia nic dla mnie nie dała, na git 1.9.4.

— djangofan

137

Możesz użyć git merge --no-commit aby zapobiec faktycznemu zatwierdzeniu scalania, a jeśli nie podoba ci się, jak działa scalanie, po prostu zresetuj do pierwotnej głowy.

Jeśli zdecydowanie nie chcesz sfinalizować scalania, nawet jeśli jest to szybkie przewijanie do przodu (a zatem z definicji nie ma konfliktów), możesz również dodać --no-ff.

— Bursztyn
źródło

Nie sądzę, że git merge --abortistnieje - może masz na myśli git reset --merge?

— Mark Longair,

Nie, po prostu zapomniałem, że w przeciwieństwie do rebasetego nie ma --abortfor git merge.

— Amber,

7

Ja też bym się --no-ffdorzucił. Aby zapobiec występowaniu ff scalania.

— Andy

1

@ Andy's --no-ffjest tutaj prawie obowiązkowe, ponieważ --no-commitnie zatrzymuje szybkich zmian.

— jackr

1

@Anant Anand Gupta - to dobra sztuczka, ale powinna wyglądać następująco: git config --global alias.tm "merge --no-commit --no-ff"

— pasx

109

Jeśli chcę porównać zmiany w gałęzi tematycznej do opanowania, najłatwiej i najbezpieczniej jest wykonać następujące czynności:

git checkout master
git checkout -b trial_merge
git merge topic_branch

Po zakończeniu scalania łatwo jest zobaczyć skonsolidowaną zmianę od wzorca

git diff master

Po zakończeniu po prostu usuń gałąź trial_merge

git checkout master
git branch -D trial_merge

W ten sposób gałąź główna nigdy się nie zmienia.

— Ian
źródło

4

Możesz także robić git checkout --detachi testować, co chcesz. Później, jeśli chcesz zachować zmiany, zrób to git checkout -b new_branch. A jeśli chcesz odrzucić swoje zmiany, wyewidencjonuj dowolną gałąź ( git checkout master).

— Shayan Toqraee

Jeśli topic_branchjest duży (jak to prawdopodobnie ma miejsce w przypadku tego pytania w pierwszej kolejności), diff masterwynik jest prawdopodobnie zbyt duży, abyś mógł się przyjrzeć, jeśli scalanie ma powodować konflikty.

— Crescent Fresh,

Zdecydowanie bardzo mi się to podoba ... bezpieczne i proste.

— leo

4

Używam :

git merge --ff-only

zgodnie z dokumentacją :

Odmawiaj scalenia i wyjdź ze statusem niezerowym, chyba że bieżący HEAD jest już aktualny lub scalenie można rozwiązać jako szybkie do przodu.

To naprawdę nie jest symulacja, ponieważ nastąpi szybkie połączenie w przypadku braku konfliktów między dwiema gałęziami. Ale w przypadku konfliktów zostaniesz poinformowany i nic się nie stanie.

— Ortomala Lokni
źródło

4

Mogłem ostatnio używać git merge --abort. Można tego jednak użyć tylko w przypadku konfliktu scalania. Jeśli jesteś pewien, że nie chcesz zatwierdzać, użyj innych wymienionych powyżej metod.

— fasola5
źródło

1

Jakie inne metody wymienione powyżej? Wszyscy wspominają git merge --abort. Powinieneś w przyszłości potwierdzić swoją odpowiedź, określając, kto napisał odpowiedź, do której się odnosisz.

— Michael Fulton

3

Dlaczego po prostu nie utworzyć gałęzi jednorazowej (git checkout -b) i nie przeprowadzić w niej testowego scalania?

— Mohan S Nayaka
źródło

1

To, co sugerujesz, jest w rzeczywistości odpowiedzią Iana wyrażoną zwięźle :)

— tzot

0

Nie wiem dokładnie, czy to jest twój przypadek , ale twoje pytanie pamiętaj, że czasami uruchamiam funkcję, zobowiązuję się w ciągu dni i wiele razy scalam na nim development.

W tym momencie tracę kontrolę nad dokładnymi plikami, które zmieniłem i dowiem się o tym dopiero, gdy moja funkcja zostanie zamknięta, a mój kod zacznie się rozwijać.

W tym przypadku dobrym sposobem, aby dowiedzieć się, jakie modyfikacje zostały wprowadzone (nie inne od scalenia), jest użycie Sourcetree.

Musisz kliknąć prawym przyciskiem na gałęzi podstawowej i wybrać Diff Against Current:

Następnie sourcetree pokaże ci wszystkie modyfikacje, które zostaną scalone, jeśli scalisz swoją gałąź z gałęzią podstawową.

Oczywiście nie pokaże konfliktów, ale jest użytecznym narzędziem przy fuzjach.

— Lucas Amorim Silva
źródło