7

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?

deep
  • 99
  • 1
  • 2
  • 8
  • 3
    Thanks for negative marking but would you care to explain why so – deep Jul 19 '16 at 07:17
  • From your description it is very hard to understand what actually has happened. If you could provide an example of overwriten changes you would get more useful responses. Usually git does not overwrite anything during merge. – max630 Jul 21 '16 at 05:33
  • Ok. But you said very interestingly ambiguous statement ,if you can answer me ,that would help me not to get trapped in same situation. You said **Usually** git does not overwrite anything **during** merge. So do u mean git does overwrite but in some other operation but not in merge? – deep Jul 21 '16 at 07:41
  • With default [*strategy*](https://git-scm.com/docs/git-merge) and default text [*merge driver*](https://git-scm.com/docs/gitattributes), if there is no conflict, git never overwrites anything at merge. If there is a conflict then what "git does" fully depends on how person performing merge resolves the conflicts. For generic learning about what git can do you could check documentation at https://git-scm.com/docs/ , for example. – max630 Jul 21 '16 at 11:23
  • deep, did you manage to clarify this? I'm having exactly the same problem and no idea why when I do 'git merge' it's overwriting my changes? Do you know which command should I run for that? – mickael Dec 03 '16 at 16:17

4 Answers4

5

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

jp2g
  • 682
  • 4
  • 8
3

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:

Community
  • 1
  • 1
Vidur
  • 1,442
  • 2
  • 17
  • 37
  • Rebase simply commits on top of that branch if I am not wrong.But as you mentioned git pull --rebase would stash my work then that could be used.Thanks – deep Jul 19 '16 at 07:20
  • `pull --rebase` would stash your changes only from Git 2.6, with the `git config rebase.autostash true` used in combination of `git pull.rebase true`: http://stackoverflow.com/a/30209750/6309 – VonC Jul 19 '16 at 07:27
  • No luck I tried rebasing but its still the same situation overwriting files, in other platform I do same but its merging properly. I don't know whats going wrong.I don't want to use pull request in this as I am afraid remote repo will be overwritten. – deep Jul 20 '16 at 05:10
  • Firstly, there's nothing to be afraid of with git. You can revert to any previous commit fairly easily. I would recommend checking out a backup branch and using that to test the various kinds of merges you can do. Typically you should get a merge conflict if you both edited the exact same file. – Vidur Jul 20 '16 at 05:40
  • If you can reproduce this issue in a test repo, and put it up on Github (with public access), it would be considerably easier to debug the issue. – Vidur Jul 20 '16 at 05:40
1

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.support@kozbara.com</div>
=======
<div id="footer" >
please contact us at support@kozbara.com</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.

joker
  • 3,416
  • 2
  • 34
  • 37
  • 4
    This isn't correct. Sometimes git overwrites the change in the same line from Branch A to Branch B and there isn't a conflict separating the two. I've discovered the same thing happening when I merge and I came across this. – Rahul P Apr 09 '20 at 08:02
  • Was the overwritten line update in both branches after they diverged from their common ancestor? – joker Apr 09 '20 at 15:14
  • I don't fully recall now. I managed to fix the issue by manually copying over changes. I'll post back here if I encounter this again. – Rahul P Apr 09 '20 at 16:00
1

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.

psydj1
  • 181
  • 10