git: Dlaczego "Merge branch" master "z ..."? kiedy ciągnie się i pcham

Nadal jestem młodym nowicjuszem. Zmodyfikowałem niektóre pliki źródłowe i zatwierdziłem. Potem zrobiłem git push. Ale mam ten błąd.git: Dlaczego "Merge branch" master "z ..."? kiedy ciągnie się i pcham

To /foo/bar/ ! [rejected]  master -> master (non-fast-forward) 
error: failed to push some refs to '/foo/bar/' To prevent you from 
losing history, non-fast-forward updates were rejected Merge the 
remote changes before pushing again. See the 'Note about 
fast-forwards' section of 'git push --help' for details.

odrzucić ten wydaje się, że nie git pull przedtem push. Tak, zrobiłem git pull. W porządku, były dwa zmodyfikowane pliki przez innych.

Następnie udało mi się pomyślnie uzyskać git push.

Pytanie: W tym przypadku, widzę jeszcze jeden dziennik jak po moim pierwotnym popełnienia wiadomości:

commit 59e04ce13b8afa... 
Merge: 64240ba 76008a5 
Author: Jone Doe <[email protected]> 
Date: Fri Mar 15 11:08:55 2013 -0700 

    Merge branch 'master' of /foo/bar/

I to jest mój oryginalny popełnić wiadomość.

commit 64240bafb07705c... 
Author: Jone Doe <[email protected]> 
Date: Fri Mar 15 11:06:18 2013 -0700 

    Fixed bugs and updated!

Chciałbym zrozumieć, dlaczego dodano "scal master mapy lokalizacji".

Źródło

2013-03-15 Nullptr

Możliwy duplikat [Git pull skutkuje nieistotnym "połączeniem gałęzi" wiadomości w dzienniku zatwierdzenia] (http://stackoverflow.com/questions/8509396/git-pull-results-in-extraneous-merge-branch-messages-in-commit-log), który ma dużo bardziej szczegółowe odpowiedzi. –

Po wykonaniu git-pull modyfikacje z odległego oddziału zostały scalone w lokalnym oddziale. Automatycznie wygenerowany commit oznacza to.

Scalenie mogło spowodować konflikty, które następnie musiałyby zostać rozwiązane ręcznie. W twoim przypadku tak się nie stało, a git mógł zająć się wszystkim.

Źródło

2013-03-15 18:26:08

istnieje sposób na uniknięcie takiego dodatkowego zatwierdzenia? Na przykład poprzez uwzględnienie scalających modyfikacji w bieżącym zatwierdzeniu (* Naprawiono błędy i zaktualizowano! * Powyżej)? Ponieważ to zanieczyszcza historię dziennika. – Kalvn

Git spróbuje wykonać szybkie przewijanie do przodu, jeśli zdalny oddział znajduje się przed lokalnym odgałęzieniem, tj. Zdalny oddział ma pewne zatwierdzenia na podstawie zatwierdzeń lokalnego oddziału. W takim przypadku nie ma dodatkowego zatwierdzenia. Dodatkowe zatwierdzenie pojawia się tylko wtedy, gdy rozbieżne są historie obu oddziałów. W takim przypadku możesz przepisać historię commitowania lokalnej gałęzi używając 'git rebase' lub' git pull --rebase', wykonując szybkie przewijanie do przodu. Rebasing ma jednak swoje wady, a dodatkowe commge nie zawsze są złe - po prostu rejestrują przebieg rozwoju. –

Dzięki za wyjaśnienie :) – Kalvn

Gdybym mógł tam być zmiany przez innych, może to być dobry pomysł, aby zrobić git pull --rebase (tj, dodać nowe zmiany po odległych zmian; może to znaleźć konflikty trzeba by rozwiązać), a następnie git push wynik. Bądź ostrożny, to tworzy nowe zatwierdzenia, które nigdy wcześniej nie istniały (jak to ma miejsce w przypadku przepisywania historii), ale daje czystą, liniową historię (bez plątania scaleń).

Źródło

2013-03-16 01:53:21 vonbrand

git: Dlaczego "Merge branch" master "z ..."? kiedy ciągnie się i pcham

Odpowiedz

Powiązane problemy