ChatGPT解决这个技术问题 Extra ChatGPT

How do I 'overwrite', rather than 'merge', a branch on another branch in Git?

I have two branches, email and staging. staging is the latest one and I no longer need the old changes in email branch, yet I don't want to delete them.

So I just want to dump all the contents of staging into email so that they both point to the same commit. Is that possible?


J
John Cvelth

You can use the 'ours' merge strategy:

$ git checkout staging
$ git merge -s ours email # Merge branches, but use our (=staging) branch head
$ git checkout email
$ git merge staging

EDIT 2020-07-30:

I thought a bit more about this question and possible solutions. If you absolutely require the merge parents in the correct order, need to perform this action with a single command line invocation, and don't mind running plumbing commands, you can do the following:

$ git checkout A
$ git merge --ff-only $(git commit-tree -m "Throw away branch 'A'" -p A -p B B^{tree})

This basically acts like the (non-existent) merge -s theirs strategy. You can find the resulting history in the plumbing branch of the demo repository

Not very readable and not as easy to remember compared to the -s ours switch, but it does the job. The resulting tree is again the same as branch B:

$ git rev-parse A^{tree} B^{tree} HEAD^{tree}
3859ea064e85b2291d189e798bfa1bff87f51f3e
0389f8f2a3e560b639d82597a7bc5489a4c96d44
0389f8f2a3e560b639d82597a7bc5489a4c96d44

EDIT 2020-07-29:

There seems to be a lot of confusion as to what the difference between -s ours and -X ours (the latter being equivalent to -s recursive --strategy-option ours) is. Here's a small example to show the two results from using these two methods. I also recommend reading the question and answers of (Git Merging) When to use 'ours' strategy, 'ours' option and 'theirs' option?

First, setup a repository with 2 branches and 3 commits (1 base commit, and 1 commit per branch). You can find the sample repository on GitHub

$ git init
$ echo 'original' | tee file1 file2 file3
$ git commit -m 'initial commit'
$ git branch A
$ git branch B
$ git checkout A
$ echo 'A' > file1
$ git commit -m 'change on branch A' file1
$ git checkout B
$ echo 'B' > file2
$ git commit -m 'change on branch B' file2

Now, let's try the strategy option (doesn't really matter if we use theirs or ours for this explanation):

$ git merge -X ours A
$ cat file*
A
B
original

We end up with a merge of both branches' contents (branch "strategy-option" in the sample repo). Compare that to using the merge strategy (re-init your repository or reset branch, before executing the next steps):

$ git merge -s ours A
$ cat file*
original
B
original

The result is quite different (branch "merge-strategy" in the sample repo). With the strategy option, we get a merge result of both branches, with the strategy we throw away any changes which happened in the other branch.

You will also notice that the commit created by the merge-strategy in fact points to the exact same tree than the latest commit of "our" branch, while the strategy-option created a new, previously unseen tree:

$ git rev-parse A^{tree} B^{tree} merge-strategy^{tree} strategy-option^{tree}
3859ea064e85b2291d189e798bfa1bff87f51f3e
0389f8f2a3e560b639d82597a7bc5489a4c96d44
0389f8f2a3e560b639d82597a7bc5489a4c96d44
5b09d34a37a183723b409d25268c8cb4d073206e

OP indeed asked for "I no longer need the old changes in […] branch" and "So I just want to dump all the contents of [A] into [B]", which is not possible to do with a strategy option. Using the 'ours' merge strategy is one possibility of many, but likely the easiest (other possibilities include using low level commands of Git such as write-tree and commit-tree).


I tried this, and it seems backwards to me? Doesn't this dump the contents of email into staging and not the other way around?
@Max I had the same confusion and it caused me a lot of trouble. You need do this command from the newer branch (staging), and then do a normal merge/PR to your old branch (email).
Why the ; at the end of each command? I did without the ; and it seems to be working. Also this answer is incomplete, the third step is to checkout the old branch (email) and then merge with staging again.
git rebase -s theirs <oldbranc> <newbranch> works as well (no matter which branch you are). Note that in rebase 'theirs' is actually the newbranch because 'ours' is the head we're currently applying the commits to.
@Rolf: but rebase will get rid of the merge information and flattens history. Not necessarily what you are after. Also not a good idea, if you are working with already-published history.
P
Peter Mortensen

If you just want the two branches 'email' and 'staging' to be the same, you can tag the 'email' branch, then reset the 'email' branch to the 'staging' one:

$ git checkout email
$ git tag old-email-branch
$ git reset --hard staging

You can also rebase the 'staging' branch on the 'email' branch. But the result will contains the modification of the two branches.


you probably mean git checkout, git check does not exist to my knowledge
You're right, I'm so used to tab completion of git command that I always write "git check" to write "git checkout " ! Corrected.
git reset breaks the repo of other people that have cloned your repo
I believe this is the right answer. email branch's head should just point to the same head of staging and they both will have the same commits, same history.
B
Brugolo

I've seen several answers and that's the only procedure that let me fix that without any conflicts.

If you want all changes from branch_new in branch_old, then:

git checkout branch_new
git merge -s ours branch_old
git checkout branch_old
git merge branch_new

once applied those four commands you can push the branch_old without any problem


Your answer really fit my issue best as I didn't want to reset the HEAD, just state a preference for the newer files in the newer branch when merging things into the older one, and worked without issue! +1
I pushed my branch_new to remote after the "ours merge", and this method worked for me. Was it necessary for me to push? Or would it have worked without? (Wasn't sure if it would use the local branch or remote). Thanks!
Why can't you simply do the below? git checkout branch_old git merge -s theirs branch_new Clue taken from stackoverflow.com/questions/14275856/…
It says , could not find merge strategy 'theirs'.
Works perfectly for me, has the advantage of not reseting anything
S
Shyam Habarakada

The other answers gave me the right clues, but they didn't completely help.

Here's what worked for me:

$ git checkout email
$ git tag old-email-branch # This is optional
$ git reset --hard staging
$
$ # Using a custom commit message for the merge below
$ git merge -m 'Merge -s our where _ours_ is the branch staging' -s ours origin/email
$ git push origin email

Without the fourth step of merging with the ours strategy, the push is considered a non-fast-forward update and will be rejected (by GitHub).


That makes the merge-commit message wrong, but yeah, it works great.
cdunn2001, I'm curious. What was the merge-commit message you were expecting and how did that get messed up with this?
It says "Merge remote-tracking branch 'origin/email' into email". It does not mention staging. No big deal though. Just amend the commit, or use merge -m 'This is not my beautiful house.' -s ours origin/email.
@ShyamHabarakada , i do as you say , and i get the problem about non-fast-forward update . because nothing happens when i do the 4th step.
4th step requires you to use origin/email, it doesn't work with just local email.
j
jsarma

If you're like me and you don't want to deal with merging, you can do the above steps, except use force instead of merge, because it will create a distracting log paper trail:

git checkout email
git reset --hard staging
git push origin email --force

Note: This is only if you REALLY never want to see the stuff in email again.


git push origin email --force didn't worked for me as Step2 left branches diverged. So after Step2, this is what I did: git reset origin/email and then git push
This is exactly what was asked in question - "how to overwrite rather than merge". Should be accepted answer.
If you still want to see the stuff in the email branch, just tag it before push, e.g., git tag old-email-branch. You will then be able to keep the previous stuff by the tagged version.
m
mjjf

WARNING: This deletes all commits on the email branch. It's like deleting the email branch and creating it anew at the head of the staging branch.

The easiest way to do it:

//the branch you want to overwrite
git checkout email 

//reset to the new branch
git reset --hard origin/staging

// push to remote
git push -f

Now the email branch and the staging are the same.


Warning: This deletes all commits on the email branch. It's like deleting the email branch and creating it anew at the head of the staging branch.
Will this create a problem with multiple people working with the branches? If they git pull email, will they now get the email branch that is its own branch but is identical, if no commits, the same as staging?
V
Vadim Kotov

I wanted to merge two branches so that all the contents in old_branch to be updated with the contents from new_branch

For me this worked like a charm:

$ git checkout new_branch
$ git merge -m 'merge message' -s ours origin/old_branch
$ git checkout old_branch
$ git merge new_branch
$ git push origin old_branch

M
Manohar Reddy Poreddy

Other answers looked incomplete. I have tried below in full, and it worked fine.

NOTE: 1. Make a copy of your repository before you try below, to be on safe side.

Details: 1. All development happens in dev branch 2. qa branch is just the same copy of dev 3. Time to time, dev code needs to be moved/overwrite to qa branch

so we need to overwrite qa branch, from dev branch

Part 1: With below commands, old qa has been updated to newer dev:

git checkout dev
git merge -s ours qa
git checkout qa
git merge dev
git push

Automatic comment for last push gives below:

// Output:
//  *<MYNAME> Merge branch 'qa' into dev,*  

This comment looks reverse, because above sequence also looks reverse

Part 2:

Below are unexpected, new local commits in dev, the unnecessary ones so, we need to throw away, and make dev untouched.

git checkout dev

// Output:
//  Switched to branch 'dev'  
//  Your branch is ahead of 'origin/dev' by 15 commits.  
//  (use "git push" to publish your local commits)


git reset --hard origin/dev  

//  Now we threw away the unexpected commits

Part 3: Verify everything is as expected:

git status  

// Output:
//  *On branch dev  
//  Your branch is up-to-date with 'origin/dev'.  
//  nothing to commit, working tree clean*  

That's all. 1. old qa is now overwritten by new dev branch code 2. local is clean (remote origin/dev is untouched)


hahaha thanks a lot!! I'm new using gits repositories and you save me!! very good explanation!!! it works for me!!
happy to know :)
great step-by-step answer, thank you
f
frandroid

How about:

git branch -D email
git checkout staging
git checkout -b email
git push origin email --force-with-lease

@emptywalls because it does a force push without warning the user that it can be rejected by the server, nor it explains why it's needed. That said, it's a viable option for a one-developer-project
@DavidCosta why would this get rejected by the server? this is a simple delete email branch & copy staging to email'... So I just want to dump all the contents of 'staging' into 'email' so that they both point to the same commit' - that is exactly what is happening here.
@ArekS it can be refused by a server side hook if the branch is set as "protected" e.g. in GitLab. Problem is that if someone else derived his branch from email before this operation and then tries to push, the references don't match anymore (because some commits simply vanished)
I edited the original from --force to --force-with-lease, that does the trick in a non-destructive way.
This is the best way if you just want to blow away a branch and start it clean from the source branch.
l
lenz

What you want is this (actually the exact inverse of the currently accepted answer):

git checkout email
git merge --strategy-option=theirs staging  

What this does is:

email branch files will now be exactly the same as staging branch

email branch's history will be maintained

staging branch's history will be added to email history

As added value, if you don't want all of staging branch's history, you can use squash to summarize it into a single commit message.

git checkout email
git merge --squash --strategy-option=theirs staging  
git commit -m "Single commit message for squash branch's history here'

So in summary, what this second version does is:

email branch files will now be exactly the same as staging branch

email branch's history will be maintained

A single commit will be added on top of email branch's history. This commit will represent ALL the changes that took place in the staging branch


Reading the merge docs. It looks like we cannot use --strategy-option=theirs
didn't work for me. results in conflicts although "theirs" is used. the accepted answer with first reverse merging using -s ours did work though.
W
Willa
git checkout email
git merge -m "Making email same as staging disregarding any conflicts from email in the process" -s recursive -X theirs staging

This answer would have been clearer to me if the comment was made separate from the merging comment in the command. Explain briefly what -X does and how it affects this merge. Thanks though. Made me look it up :)
@noelicus thanks for the comment and you are right. I might edit the answer in the future.
J
Jan Kyu Peblik

This one doesn't alter the original newer branch, and gives you the opportunity to make further modifications before final commit.

git checkout new -b tmp
git merge -s ours old -m 'irrelevant'
git checkout old
git merge --squash tmp
git branch -D tmp
#do any other stuff you want
git add -A; git commit -m 'foo' #commit (or however you like)

z
zjk

I tried @knittl's write-tree/commit-tree approach.

branch-a: the kept branch

branch-b: the abandoned branch

// goto branch-a branch
$ git checkout branch-a

$ git write-tree
6fa6989240d2fc6490f8215682a20c63dac5560a // echo tree id? I guess

$ git commit-tree  -p branch-a -p branch-b 6fa6989240d2fc6490f8215682a20c63dac5560a
<type some commit message end with Ctrl-d>
20bc36a2b0f2537ed11328d1aedd9c3cff2e87e9 // echo new commit id

$ git reset --hard 20bc36a2b0f2537ed11328d1aedd9c3cff2e87e9

N
Noah Nuebling

This will merge two branches old and new and choose the new version on every merge conflict:

git checkout old
git merge new
git checkout --theirs .
git add .
git commit