git merge overwrites changes

Question

Can anyone help in avoiding git merge issue. I am trying to merge my branch lets say my_branch into another branch lets say another_branch. As another_branch is base branch.So to add work done in my_branch ,First I am merging my_branch. To do so I am doing these steps.

git checkout another_branch
git pull anothr_branch

Once I have updated latest changes in another_branch I switch to my_branch

git checkout my_branch
git merge anothr_branch

And before doing all this yes I am committing and staging my changes to save it locally. So no doubt to lose any of my changes.

But I don't see all changes of another_branch.So I am calling it overwrite.

What could be the reason?

Answer 1

Here's a daily routine we've been using in a multi-developer, multi-team environment that's simple enough and works well.

Say you have a dev branch that stores the current in-development version of your product. A master branch that stores your current production version. Every developer has his own branch for a feature being implemented or a bug fix.

Every morning, all devs do the following:
Checkout dev.
Pull.
Checkout dev's working branch.
Rebase onto dev

Throughout the day, the above may repeat. Developers make merge requests to another developer designated as the maintainer of the dev branch.

Developer:
Commit changes.
Push

Dev maintainer:
Checkout branch from developer to merge.
Pull.
Checout dev.
Merge from branch from developer to merge.
Push

Answer 2

What you probably want to do is use rebase. A rebase places commits in the destination branch after the commits on the source branch.

So locally, if I'm on my feature branch, I will use git rebase master - this places the commits I have on my feature branch on top of the newest commits in master.

For a remote branch, I typically use git pull --rebase, which stashes your changes, pulls the changes from the server, places your changes on top of the newest changes from the server.

The best visual guide to how rebasing works, that I've come across is this one by Atlassian.

You can find out more about rebase at these resources:

• man git-rebase
• git-scm guide on rebasing
• When do you use git rebase instead of git merge?

Answer 3

Git doesn't overwrite until you mark the files with conflicts as resolved (even though if they really aren't).

Git doesn't try to be smart with merging. When you merge, if it can merge cleanly, it will do so. If it cannot, it will halt the merge process and mark the conflicts which you should resolve manually. After you finish resolving conflicts of a file, you should mark it as resolved with the command git add <file>... (the same command you use to track files).

Git marks the conflicts like so:

<<<<<<< HEAD:index.html
< div id="footer" > contact : [email protected]</div>
=======
<div id="footer" >
please contact us at [email protected]</div>
>>>>>>> anotherBranch:index.html

The upper part (the part before ====) is at HEAD from the file index.html. The lower part is from the branch named anotherBranch from the same file.

Maybe you would like to read this part from git tutorial.

Answer 4

I resolved an issue with the following branches layout:

featureA - branched from develop, a lot of changes across all files. Didn't work on it in a long time.

develop - current release, bug fixes, other new features that needed to be released. Worked on it recently.

I wanted all the new stuff from Develop to be on the featureA. So I did:

1. Merge Develop into featureA -> overwrote everything in featureA
2. Merge featureA into copy of develop to test if it changes anything -> same as above
3. Then I tried rebasing

On featureA branch:

git rebase develop

(which would move the entire feature branch on top of the develop branch and keep all the commits) -> it didn't. It overwrote everything with develop.

Then: On develop branch:

git rebase featureA

(this moved entire develop branch on top of the featureA) And that worked! However, there were conflicts which makes sense because files were edited on both, but that is what I wanted because I could now pick and choose.

error: could not apply fa39187... something to add to patch A

So then I would resolved the conflict (pick the changes I wanted...sometimes picked something from featureA and from develop within the same file) and would commit and push and then continue with the rebasing until the next commit conflict using

git rebase --continue

which would say that there is no longer a problem and that I should instead use

git rebase --skip

Which I do, and then another conflict comes and so on. So basically trying rebasing other way around allowed me to see all the code changes and one by one solve the conflicts which is what I wanted to do.