Git-分支以引入新文件而不删除旧文件

Question

I have an unusual git question, hoping someone else has done this before and can provide insight...

I'm working on workflow to add files to an existing git project. Through a series of automated steps, I was hoping to create a branch that is completely empty, introduce new files, commit those files to the remote branch, then have the user manually merge the new files so that the new changes don't automatically overwrite/damage anything in the existing project.

I've tried git checkout --orphan , which doesn't do what I want b/c it just creates a "new" history that, when merged, replaces the existing branch's contents. You can't merge these the way you would normally merge changes.

I've also tried doing a normal git checkout -b emptybranch , then manually deleting all of the files and introducing the new files. The problem with this case is that I don't want existing files to be deleted on merge - I only want new files to be included into the new project, or conflicts to be made visible for the project owner to merge themselves.

What I want is the addition/merge of new files without deleting anything existing from the existing branch (and the new branch only contains the new files, nothing else from the existing branch). Any assistance would be greatly appreciated.

Answer 1

TL;DR executive summary

I think you do want git checkout --orphan , but you want it followed by git rm -r . (and perhaps also rm -rf of any untracked files this leaves behind).

Description

I've tried git checkout --orphan , which doesn't do what I want b/c it just creates a "new" history that, when merged, replaces the existing branch's contents.

That's not quite right. What --orphan does is set things up so that the next commit on the now-current branch is itself a root commit . Using --orphan is otherwise the same as using -b , ie, the index remains full of whatever it has at the moment. The work-tree is similarly undisturbed.

If you then also empty out the index ( git rm -r . at the top level), and optionally clean out the work-tree as well (if there are any remaining untracked files), then from this point on, only new files you git add from the work-tree will be in the next commit. (You might want to commit just a README-ish file first, as is often done in the initial root commit of a new, totally-empty repository, for the same reasons that people make such a commit in a new repository.)

Later, if and when you go to git merge this branch, Git now (as of 2.9) rejects the attempt unless you add --allow-unrelated-histories . This is because there is no merge base between the orphan branch and the other branches in your repository. Adding --allow-unrelated-histories tells Git to use a synthetic empty commit (actually, the empty tree ) as the merge base. Hence during the merge, all files in both branch tips are viewed as newly-added, and if any two files are identified (ie, have the same path name in both tip commits), you will get an add/add conflict on them and be forced to resolve this manually. Given your problem description, it sounds like this is what you wnat.