有没有办法合并两个分支而不会丢失文件和更改？

Question

is there a way to merge two branches without losing files and changes?

I have this situation:
Branch A contains:

• file A (different from file A from branch B)
• file B (different from file B from branch B)

Branch B contains:

• file A
• file B
• file C

Now I want to merge the branch A to branch B, the problem is that when I try to do that all changes from branch B are ignored, even the file C is deleted. How can I do that without losing changes from branch A and also from branch B? Because git didn't show me any conflicts between these files.

Answer 1

You can do the merge by checking out branch B and having no working changes, then run the following command git merge A .

The result will likely require a manual editing of the files to resolve conflicts before doing the final commit. The following output when initiating the merge would indicate need for a manual merge.

CONFLICT (content): Merge conflict in [file A] or in file B. Or both.

Fix the conflicts manually, then do a git add [file A] to continue on with the merge. When all code conflicts are resolved and the code is compiling do a git commit to complete the merge commit into branch B.

Answer 2

Your fundamental error here lies in thinking that git merge has two inputs—your branch and some other branch. This is not the case: it has three inputs, none of which is a branch . The three inputs are commits .

Let's draw some commits, and the branch names that remember the last commit that goes in each branch:

          o--o--A   <-- branch-A
         /
...--o--*
         \
          o--o--B   <-- branch-B

If you run git checkout branch-A , what you get is commit A , because the name branch-A points to that particular commit. The same holds for git checkout branch-B . Comparing these two commits shows some difference(s) in some file(s). That does matter, but not all that much .

From commit A , we can work backwards (as git log would) to an unnamed commit, then another unnamed commit, then commit * . From B , we can do the same thing, and if we do we arrive also at commit * . So commit * —the merge base of the proposed merge operation—is the best common commit , the best commit that's on both branches.

The way merge works is to run two git diff s:

• The first compares the snapshot in commit * to that in commit A , to see what someone changed on that path.
• The second compares the snapshot in commit * to that in commit B , to see what someone changed on that path.

Then Git combines these two sets of changes. The resulting combined changes, if they have no conflicts, get applied to the snapshot from commit * .

Having combined the two sets of changes and applied them correctly—or as correctly as Git can determine—Git goes on to make a new commit, mostly in the usual way. The new commit causes whichever branch you have checked out (one of the two branch-A or branch-B names) to get updated to point to the new commit. The new commit has two parents, which are commits A and B . So the end result is:

          o--o--A
         /       \
...--o--*         M   <-- branch-<whichever> (HEAD)
         \       /
          o--o--B

with whichever branch name didn't move, still pointing to either A or B .

The snapshot in new merge commit M is that from * , plus both sets of changes . If A didn't change something from * , but B did change something from * , you get B 's changes. If A did change something and B didn't, you get A 's changes. If both changed the same lines of the same file, then you get a merge conflict—and you have to finish the merge job and make M yourself.

(If file C is in one of A and B , but not in the other, file C must either have been created-since- * or removed-since- * . Merge combines create new file with nothing by taking the new file. It combines remove old files with nothing by removing the old file. Given your text description, C must exit in * , giving you the remove file action.)