Klar geht das. Du kannst die merge strategie "ours" angeben, dann werden alle konflikte zu gunsten des aktuellen standes aufgelöst.
Allerdings würde ich grundsätzlich empfehlen statt einem git merge einen interaktiven rebase zu machen. Der unterschied ist, beim merge tust du praktisch 2 git pfade zusammenführen mit einem merge commit, beim rebase nimmst du einfach deine Änderungen von deinem branch, und hängst sie an die neuste version des anderen branches an.
Also z.B. sagen wir mal du willst ein neues feature auf basis von Branch A machen in Branch B. Wenn du branch B erstellst ist Branch A die commit historie:
Dann machst du ein paar commits in B:
Währenddessen wurde zu A allerdings A5 und A6 hinzugefügt. Bei einem Merge hast du dann
Das Problem ist das du jetzt parallele branches hast. Also wenn du von Merge 1 commit zurückgehen willst, wo landest du B2 oder A6? Egal was du wählst, einer der beiden subbranches geht verloren und du darfst den merge nochmal machen.
Bei einem rebase hingegen fügst du einfach die neuen commits ein und endest mit:
Was viel sauberer und viel einfacher zu managen ist. Noch dazu kannst du in einem Rebase die commit history aufräumen, du kannst commits umsortieren, zusammenfassen, aufsplitten, löschen, neue hinzufügen, nachrichten ändern, etc.
Um einen rebase zu Branch A zu machen einfach auf branch B dann:
Dann öffnet sich dein GIT editor (z.B. vim) mit einer liste mit allen betroffenen commits (Also B1, B2, A5 und A6). Hier kannst du jetzt erst einmal schauen ob du mit dem Layout der commits so zufrieden bist, oder due wie oben erwähnt, reiehenfolge ändern willst, zusammenfassen willst oder löschen willst. In den allermeisten fällen solltest du aber nix ändern müssen.
Danach wenn du das dokument speicherst und den editor schließt, fängt der rebase an. Dabei wird durch jeden commit gegangen der sich geändert hat und geschaut ob du merge konflikte hast. Die musst du einfach ganz normal beheben und evtl neu commiten. Am ende ein git rebase --continue machen und der rebase prozess geht weiter.
Wenn du auf Branch B 3 commits hast, musst du im schlimmsten Fall 3 mal merge konflikte lösen. Das wird zwar bei sehr vielen commits irgendwann echt langwierig, aber für das endergebnis lohnt es sich. Die Git historie ist viel übersichtlicher und rollbacks sind viel einfacher zu machen