Git-Zusammenführung ohne automatische Übergabe

Question

Ist es möglich, eine git merge , aber ohne eine Zusage?

"man git merge" sagt dies:

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.

Aber wenn ich versuche, die git merge mit dem --no-commit wird immer noch automatisch übertragen. Hier ist, was ich tat:

$> ~/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)

Eine nachträgliche git log zeigt alle Commits aus dem v1.0-Zweig an, die in Master zusammengeführt wurden.

Answer 1

Sie könnten auch Folgendes tun

git cherry-pick <commit hash> 

für jeden Commit, wenn Sie den Commit-Verlauf beibehalten wollen...

Ich sehe nicht wirklich einen "netten" Weg, um mehrere Commits aus einem anderen Branch mit dem git merge Befehl, ohne dass ein Merge Commit hinzugefügt wird (d.h. nur die Commits, die Sie einbeziehen wollen)

Answer 2

Eine alte Frage mit vielen Antworten, aber sie ist zu umfangreich für einen Kommentar.

---

Wie bereits in einer anderen Antwort erwähnt, führte das Zusammenführen von v1.0 in Master zu einem Fast-Forward-Merge. In Wirklichkeit gab es keine Zusammenführung. Der v1.0-Tag hatte einen Commit, dessen übergeordneter Commit die Spitze von master war. Ich habe einfach den Zeiger für master um einen Commit vorverlegt.

Wenn das zu einem schlechten Merge führt, haben Sie uns *wirklich" einen schlechten Commit am v1.0 Tag gegeben.

Die angemessenere Lösung ist es, v1.0 schnell in Master zusammenzuführen und dann einen Commit an Master hinzuzufügen, der den fehlerhaften Code korrigiert. Danach löschen Sie entweder das Tag v1.0 und erstellen es neu, oder Sie setzen das Tag v1.0 neu und erzwingen einen Push des Tags. Besser noch, erstellen Sie ein v1.0.1 Tag aus dem Commit, das v1.0 korrigiert.

Jede andere Antwort weist Sie auf die falsche Lösung aus der Sicht der Kodierung hin.