CODEWITHSUNDEEP
gitgithubmergeversion-control
O_K
O_K

Reputation: 1080

Why merging master branch to feature branch is deleting files from feature branch in GIT?

I have a feature branch A and I have done few commits in the feature branch. My master branch is ahead of my feature branch. When I am trying to merge my master branch to feature branch , my feature branch files which are committed and pushed to remote of my feature branch gets deleted. I am getting no merge conflict while merging master to feature branch. When I delete the local feature branch and checkout again from remote of feature branch, those deleted files reappear but as soon as I merge updated master(without changes from this feature branch A), the files gets deleted. Can someone help me out as what is happening ?

Upvotes: 3

Views: 2412

Answers (2)

O_K
O_K

Reputation: 1080

I figured out the reason for this issue. The files were added to master in past and were deleted so when I was trying to merge master to feature branch, GIT used to ignore those files. I fixed that by following below steps :

  1. Make some changes to those files.
  2. Git commit those files.
  3. Merge master to feature branch.

Upvotes: 0

torek
torek

Reputation: 487755

The git merge command performs a "true merge" by:

  1. Locating the merge base commit. If you are on branch B now, and are running git merge M, you can find this commit's hash ID(s) yourself with:

    git merge-base --all B M

    Ideally, this prints just one commit hash ID; if it prints two or more hash IDs, you have an especially complex merge and must move to a more detailed answer.

  2. Using the equivalent of git diff --find-renames twice. One of these diff commands figures out what you changed on branch B. The other diff figures out what they changed on branch M.

  3. Combining these changes.

Your result, of combining these changes, includes deleting some file(s). You'll see that, in the two diffs generated in step 2, one of those two diffs says to delete some file, and other of the two diffs says nothing at all about that file. The result of combining the delete file xyz instruction with the do nothing at all instruction is delete file xyz, so Git follows that (combined) instruction and deletes the file.

If you don't want the file deleted, don't have deleted it. 😀 Figure out why one of these two diffs shows the file as deleted. You can run the two diffs yourself; you might wish to use --name-status to cut down on the amount of output. (You can cut down on it even further with --diff-filter, but start with just --name-status.) For instance, suppose that git merge-base prints 12604a8d0c0a7d706c7be7be607a584260042ca9. You would run:

git diff --find-renames --name-status 12604a8d0c0a7d706c7be7be607a584260042ca9 HEAD

to see what Git thinks you changed (you can type in B's branch name instead of HEAD if you like), and:

git diff --find-renames --name-status 12604a8d0c0a7d706c7be7be607a584260042ca9 M

(substitute in the actual branch name) to find out what Git thinks they changed.

If you don't like Git's merge result:

  • make changes (by adding commits to either or both branches) before merging; or
  • make changes (by adding new commits) after merging; or
  • use git merge --no-commit and make an evil merge. Read the linked question, and think hard about why you want an evil merge, before making one, because if you use some of Git's fancier options to re-perform this merge later, Git will make a non-evil merge next time, unless you carefully arrange to make the same evil merge. This tends to require a lot of knowing-what-you-are-doing.

Note that git merge sometimes doesn't perform any merges at all, and some results from git merge (e.g., with --squash) are not merge commits, even though they may have used the merge machinery to produce merged results. The noun-phrase merge commit is a very different thing from the verb to merge.

Upvotes: 2

Related Questions