Git merge bez automatycznego zatwierdzania

402

Czy można to zrobić git merge, ale bez zatwierdzenia?

„man git merge” mówi to:

With --no-commit perform the merge but pretend the merge failed and do not autocommit,
to give the user a chance to inspect and further tweak the merge result before
committing.

Ale kiedy próbuję używać git mergez tym --no-commit, nadal automatycznie zatwierdza. Oto co zrobiłem:

$> ~/git/testrepo$ git checkout master
Switched to branch 'master'

$> ~/git/testrepo$ git branch
* master
  v1.0

$> ~/git/testrepo$ git merge --no-commit v1.0
Updating c0c9fd2..18fa02c
Fast-forward
 file1 |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

$> ~/git/testrepo$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

Kolejne git logujawnia wszystkie zatwierdzenia z gałęzi v1.0 połączone w master.

git

— Selbie
źródło

616

Zanotuj wynik podczas scalania - to mówi Fast Forward

W takich sytuacjach chcesz zrobić:

git merge v1.0 --no-commit --no-ff

— manojlds
źródło

7

co jeśli jest konflikt.

— Jürgen Paul

20

@PineappleUndertheSea Szybkie przewijanie do przodu nigdy nie powoduje konfliktów. W przypadku „prawdziwego” scalenia bez szybkiego przewijania do przodu --no-commitprzełącznik działa tylko wtedy, gdy nie występuje konflikt, w przypadku konfliktu git nigdy nie zatwierdza automatycznie.

— gronostaj

38

FYI: Jeśli chcesz scalić zmiany, a następnie zatwierdzić , jakbyś ręcznie wpisał wszystkie zmiany, które scaliłeś (w przeciwieństwie do tradycyjnego scalania), musisz uruchomić rm .git/MERGE_HEADpóźniej, co zmusi Gita do zapomnienia o fuzji.

— Jonn

7

FYI: Oto przykładowe dane wyjściowe dla udanego scalenia:Automatic merge went well; stopped before committing as requested

— kevinarpe

6

Najwyraźniej git merge BRANCHENAME --no-commit --no-ffopuściłem mój obszar roboczy w stanie „ŁĄCZENIA”. Nie całkiem pewien, co to jest dokładnie, ale prosty git stash savei git stash popcykl wydawało się wrócić wszystko do normy; z tylko zmodyfikowanymi plikami z gałęzi docelowej zgodnie z przeznaczeniem, i nie ma już statusu POŁĄCZENIA.

— MoonLite

49

Nie rozumiesz tutaj znaczenia połączenia.

W --no-commitzapobiega scalającej występuje, i że tylko się dzieje, gdy połączyć dwie historie rozbieżne oddział; w twoim przykładzie tak nie jest, ponieważ Git wskazuje, że było to scalenie „do przodu”, a następnie Git stosuje sekwencyjnie tylko zatwierdzenia już obecne w gałęzi.

— Samus_
źródło

12

To niekoniecznie (imo) wyjaśni zamieszanie; Myślę, że jest to jeden (stosunkowo rzadki) moment, w którym dokumenty są w rzeczywistości jasne: git help merge=> " --no-commitWykonaj scalanie, ale udawaj, że scalanie nie powiodło się i nie zatwierdzaj automatycznie, aby dać użytkownikowi szansę na sprawdzenie i dalsze dostosowanie wyniku scalania przed zatwierdzeniem. „ Kluczem jest oczywiście użycie go w połączeniu z--no-ff

— Michaelem

6

... może byłoby mniej mylące oderwać się od ścisłej terminologii i opisać to w ten sposób: „git merge”, który wykonuje przewijanie do przodu, nie ma zatwierdzenia scalania, ponieważ tak naprawdę nie ma w ogóle scalenia. Jest to w rzeczywistości idealna sytuacja: szybkie przewijanie do przodu jest Dobrą Rzeczą, a nie ma tego dodatkowego sensu „scalania zatwierdzenia”. Jest to dobre zachowanie domyślne i nie powinno być wyłączone. (Mówiąc wprost, szybkie przewijanie do przodu jest rodzajem scalania, ale nie jest to „prawdziwe scalanie”.)

— Michał

4

jest związany z polityką projektu, w niektórych przypadkach przydatne jest włączenie / wymuszenie tych dodatkowych „zatwierdzeń scalania”, nawet jeśli jest to ff, ponieważ musisz zaznaczyć włączenie funkcji do głównej gałęzi.

— Samus_

7

...co. W porządku, myślę, że git jest praktycznie nie do uratowania. Ta odpowiedź w szczególności przekonała mnie do wypróbowania Mercurial.

— Brian Gordon,

24

Jeśli chcesz zatwierdzić tylko wszystkie zmiany w jednym zatwierdzeniu, tak jakbyś wpisał się sam, zrobi to również --squash

$ git merge --squash v1.0
$ git commit

— Adrian Li
źródło

1

Czy to ten sam efekt cogit merge v1.0 --no-commit --no-ff

— jpierson

2

Nie, inny efekt. Squash tworzy nowe zatwierdzenie z nowym hashem. Łączy wszystkie zatwierdzenia w gałęzi w jeden zatwierdzenie do scalenia.

— Kavi Siegel

23

Wolę w ten sposób, więc nie muszę pamiętać żadnych rzadkich parametrów.

git merge branch_name

Następnie powie, że twoja gałąź wyprzedza #zatwierdzenia, możesz je teraz usunąć i wprowadzić w działające zmiany, wykonując następujące czynności:

git reset @~#

Na przykład, jeśli po scaleniu jest 1 zatwierdzenie do przodu, użyj:

git reset @~1

Uwaga: w systemie Windows potrzebne są cytaty. (Jak zauważył Josh w komentarzach) np .:

git reset "@~1"

— Śrut
źródło

4

W systemie Windows potrzebne są cytaty:git reset "@~1"

— Josh

1

Kiedy jest tylko jedno zatwierdzenie w oddziale, zwykle robię

git merge branch_name --ff

— Sithu
źródło